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SECTION 1 
INTRODUCTION 


"The door to space has been opened. . . And 
that door leads inevitably to the extension of 
the hurfian environment into space and 
eventually to mankind's evolution into a space 
faring civilization." 

James N* Beggs 
NASA Administrator 

The next step towards this destiny Is the establishment of a permanent manned 
presence on a Space Station in near earth orbit. The shuttie assures a 
dependable revisit capability. The benefits of space for earth observation, 
astronomy, scientific experimentation, and high technology manufacturing in 
the high vacuum, microgravity environment have been demonstrated. Han's 
ability to function for extended periods in a space environment has been 
proven with Sky lab and the Soviet space program. The next step is to extend 
the economic applications of space by implementing a Space Station system that 
will foster an optimum use of available components and technology. 

Once a Space Station becomes established with its personnel and support 
systems, additional applications can be incorporated for relatively small 
incremental changes. The challenge is to conceive and develop a system with 
planned modularity and flexibility to permit these easy additions without 
adversely impacting the overall system optimization. 

This role of maturing space technology as a cost effective national resource 
calls for a new approach to the system concept development, it is no longer a 
question of what technology is available to put men in space for extended 
beneficial applications. The important question now is "What technology 
should be developed and in what sequence so the investment will provide a 
beneficial return in terms of more applications and lower life cycle costs?" 
Of special concern is that many of the future requirements are not yet known 
so any strategy must place a heavy weight on flexibility and modularity. 


In addressing this challenge, several groups within NASA and Industry are 
studying particular partitions of the problem (Woodcock 1, CDC 1, Wolbers 1, 
Runge I, Priest 1, Bloom 1). This Phase 1 Final Report presents the partial 
results of a study for deriving Data Systems Concepts for Space Stations. The 
work is being performed by General Electric Company on contract NAS5-2719^ to 
NASA/GilFC for Code 502. Ti^tls «tudy was conducted in parallel with other 
studies (NASA 1, NASA 2, NASA 3» NASA 4, Hann 1, TRW 1, Rockwell 1, White 1) 
that are Identifying the economic Justifications and the missions of the Space 
Station. 

The intent of this study was to Identify data system technology elements that 
have a high potential for reducing life cycle costs of Space Stations. To 
properly assess such potentials, it is necessary to identify data system 
concepts for the Space Station. Such concepts provide the necessary milieu 
within which technology alternatives, needs, and benefits can be analyzed. 
The concept development is dynamic. A Report Update will be delivered in 
April, 1983 , which will document the revised requirements, additional depth of 
trade studies, and update the concepts. 

1.1 STUDY ASSUMPTIONS 

The initial Space Station shall have the following characteristics: 

o 28.5 degree inclination orbit of approximately ADO kilometer 

altitude. 

o manned base station with colony of unmanned stations within 

*^^'energy proximity.” 

o "permanently" manned habitat, with capabilities for docking 
shuttle and stations, servicing payloads, integrating upper 
stage, construction and assembly functions. 

o some Initial time when there is no manned presence in the base 
station. 

1.2 STRAWMAN SCENARIO 

The following scenario is envisioned beginning with an Initial launch of a 
shuttle-borne core habitation facility circa I 988 . This facility will contain 
some supporting equipment to provide for minimum essential control and 
communication as well as additional resources for some manned activity while 
the shuttle is present, probably in an attached "docked" mode. At the 
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expiration of shuttle time in prbity all personnel will temporarily leave the 
facility. On subsequent return visits^ additional modules will be added to 
construct a larser core facility than would be Integrally transportable by a 
single shuttle. These subsequent revisits will occur during a relatively 
short time period^ so the unmanned duration would be measured In days or 
weeks. During the first year or two, a semi-cOntinuous manned habitation 
would evolve with tbd frequency of shuttle visits being such that there would 
be a docked or nearby shuttle vehicle there continuously. In an evolutionary 
manner, periods of a few hours or days would occur when a shuttle would be in 
orbit but not necessarily attached to the {nannnd habitation. 

During this time frame. One or more outlying platforms would be deployed to 
support other experiments and applications. By the early l99Qs, a permanent 
manned presence with some teleoperator and other EVA capability would be 
established to effect some rudimentary space construction and repair 
capability# This coutd evolve toward some on-orbIt servicing of structures or 
vehicles for subsequent transfer to higher energy orbits. This would all 
occur within the so-called *'early time frame.” 

in later phases, beginning with the late 1990s, on-orbit servicing of space 
vehicles would be a normal operation. The scenario of interest for the study 
will primarily be the "early time frame." This scenario is illustrated in 
Figure 1-1. 

1.3 INTEGRATED SYSTEM FUNCTIONS 

The functions of the Space Station data system are expected to encompass all 
those of previous long duration manned spacecraft, particularly Skylab. in 
addition, they will provide for greater autonomy and efficiency of operations 
through automation and an increasing role of providing support services for 
specific missions. In an attempt to enumerate specific functions, a tree 
structure was dev^’oped. In the broad classification, all data system 
functions were assigned to either "operational" or "mission and applications." 
This partition was chosen for several reasons. Primarily, operational 
functions represent the minimum set of requirements for the data system. They 
must be provided to sustain the Space Station. These are the more critical 
functions and thus are the ones that Justify redundant systems, alternate 
modes of operation, and high reliability requirements. The missions and 
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Figure 1-1. S'rawnvan Space Station Scenario for Early Time Frame 










application functions ara more mTssion dependent and in some cases may not be 
required^ depending on the specific mission* These are fundtione that require 
aisphesis on economic Justification. Enhancement In their implementation can 
permit trade-offs of avaiiabi 1 ity, reliability^ end degraded p»*^formance. 
Optimization can include mission benefits. These can also be optlnilzed based 
upon function mix when different mission mixes are considered. 

The tree In figure 1-2 shows the functional breakdown of these two 
partitions. These functions were adapted from the data system concept OSTA 
study (GE V). Especiailyi the mission functions will be dependent upon a 
comprehensive consideration of potential applications. As a method to 
identify those mission specific functions that wiii be advantageous to 
consider within the scope of the Space Station data system. Block 2.3, Mission 
Specific Functions has been expanded and is shown in Figure 1-3. These 
functions were analyzed against the mission in a matrix as illustrated in 
Figure 1-V. An outline of ail the functions is Included in Table 1-1. 

Appendix A contains a short description of how each function will impact the 
system. 

1.^1 APPROACH 

It would be Impractical and fruitless to try to develop a complete functional 
specification, description, or even requirements for the Space Station dat£i 
system in a study of this magnitude. Consequently, this study has taken the 
direction of emphasis on the deviations from the traditional spacecraft data 
systems. The hope is to provide a shopping list of Ideas worthy of further 
development in the belief that if even one finds Its way to operational 
deployment and improved long term cost benefits, the effort will have been 
well directed. Experts in different areas were convened in a Blue Ribbon 
Panel to express their ideas and views toward future applicable technologies. 
The results of that meeting are presented In Appendix B. 

Traditional manned spacecraft data system functions must be considered but 
only to the extent necessary to provide the context for evaluating the things 
that are new and different. The approach used in this study was to develop 
the data system architecture from the top down. The overall architecture as 
reported in initial Concepts is shown in Figure 1-5. Other concepts reported 
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Table 1-1. Outline of Space Station Data System Functions 
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Table t’^1. Outline of Space Station Data System Functions (Continued) 
t.3 DATA HANAGEMINT 


1.3.1 

Generics 



1 . 3 . 1.1 

Acquisition 


1 . 3 . 1. 2 

Capture 


1.3.1. 3 

Processing 


1 .3.1.^ 

Archiving 


1.3. 1.5 

Data Del I very 

1.3.2 

Operations 1 


1 . 3 . 2. 1 

Subsystem Status 


1 . 3 . 2. 2 

Equipment Configuration Monitor and Control 


1.3. 2. 3 

Command Execution and Verification 


1 . 3 . 2 . 4 

Computer Operations Support of all Subsystems 

1.3.3 

Crew 



1. 3.3.1 

Heal th 


1 . 3 . 3 . 2 

Duty Schedules 


1.3*3. 3 

Ski i is 


1 . 3 . 3. 4 

Entertainment 


1.3. 3. 5 

Persona! Recreation 


1 . 3 . 3 . 6 

Library Storage., Cataloging 


1.3.3. 7 

Training 

1.3.^ 

Logistics 1 


1 . 3.4.1 

Consumables 


1 . 3. ^.2 

Supplies 


1 . 3 . A. 3 

Spare Parts 


1 . 3 . 4 .^ 

Resupply Scheduling 


1.3, A, 5 

Entertainment/Recreation Supplies 


1 . 3 . 4. 6 

Crew Skills 


1.i| CONFIGURATiON MANAGEMENT 

1.4.1 Configuration Identification 

1 .,4.2 Configuration Controi 

1.4.3 Configuration Status Accounting 


2.0 Mi SSI ON AND APPLICATIONS 

2.1 MISSION PLANNING AND SUPPORT 

2. 1 . 1 Schedul inq 

2.1.2 Support 

2.1.2. 1 Maintain Data Bases 

2.1. 2.1.1 Maintain Data Base of Network Data 

2. 1.2. 1.2 Maintain Data Base of Ephemeris Data 

2. 1.2. 1.3 Maintain Data Base of Physical and 
Environmental Constants 

2. 1.2. 1.4 Maintain Data Base of Mission Specific Data 

2. 1.2.2 Simulation 


1-18 








ORIQINAl PACe IS 
OF POOR QUALITY 


Table 1-1. Outline of Space Station Data System Functions (Continued) 
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tabu l-t. Out lint of Space Station Dat a System Functions (Continued) 
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Figure 1-5. Conceptual Relationship of Space Station Data System Components 



In that same document provTde the framework for specific implementations. As 
a background to the discussion of things new and different^ some major 
deviations from the traditional data systems are Introduced* 

1.5 DEVIATIONS FROM THE TRADITIONAL 

The indefinite Mfetimei manned presence, maturing applications, Increasing 
technology performance, relaxation of power, size, and weight constraints, and 
a realistic consciousness of operating costs all drive considerations of 
deviations from traditional ground-base controlled data systems to future 
space-based systems. Some of these potential deviations are: 

o The space-based system Is the controlling element and the 

ground portion of the system is a slave component to the space- 
based portion. 

o Data base management becomes primarily an on~board rather than 
a ground function* 

o Command management becomes primarily an on-board function. 

o Definitive orbit determination is either performed or made 

available on-board. 

o On-board collision damage avoidance becomes necessary* 

o A shift in emphasis from reliability to availability is 

required. 

o On-board software changes will be permitted, 
o There will be some on-board quick- look data analysis, 
o Data will be directly broadcast to users. 

Conceptual alternatives for implementing these deviations in varying degrees 
are addressed in this report. Even though some functions are distributed 
between the space and ground, the mere capability to perform them at all on- 
board the spacecraft, even If for a limited time in a contingency mode, is a 
significant departure from tradition worthy of examination. 

1.5.1 SLAVE THE GROUND TO THE SPACECRAFT 

This represents a change in philosophy from the traditional ground controlled 
data system hierarchy. It follows from a desire and necessity to provide 
autonomous operation of the manned Space Station with minimum dependency on 
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the grour functions* This desire, when tempered with the reality that it is 
cheaper to perform some functions on the ground, results In providing the 
Space Station with the capability to remotely control some of the ground 
resources. This is particularly true of some data bases, their manipulation 
and data retrieval, and support functions. Several trade-off candidates 
result from the partitioning of data storage between the ground and the Space 
Stat ion. 


1.5.2 ON-BOARD DATA MANAGEMENT AND ACCOUNTING 

this concept places the major responsibility and the need for knowledge of the 
data base on-board the Space Station. This applies to both the data needed 
for operations (e.g., predictive ephemerldes for communication scheduling) and 
the applications data (e.g., acquisition status of earth images). In this 
concept, the Station would be given the responsibility for generating specific 
data such as location, bands, quality, and time constraints. It would be the 
responsibility of the Station to plan the acquisition, select the instruments, 
process the data, assess data quality, and to optimize the use of its 
resources to obtain the desired data quality. Cloud conditions, demands of 
other users, and on-board resource limitations would enter into the work 
planning strategy. 

Some physical data storage in this concept could be located off the Station 
since ancillary data might be better suited to acquisition and storage on the 
ground. Yet, in both concepts, the bulk of the data management would reside 
on-board. The Station should have the capability to access the remote data 
bases for needed data and to initiate requests or commands for additional 
ground data acquisition. 

1.5.3 ON-BOARD COMMAND MANAGEMENT 

This refers to command management in the broadest sense of the word and is 
intended t<? include such functions as safety and preservation of the Station. 
Consequently, the coordination of commands from users, interactive analysts, 
crew members, and various automatic systems would be vested on-board. Ini the 
traditional concept, the coordination is preplanned by teams of personnel. 
The expected complexity of the Space Station prohibits the preplanning of all 
contingency conditions and necessitates autonomy and smart computer 
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assistance. in the interest of autonomy^ the responsibility must reside on” 
board. Off-station assistance may be most effective within the concept of 
slaving the ground to the Station. 

1.5. if ON-BOARD DEFINITIVE ORBIT DETERMINATION 

The complexity of data acquisition sources and the need to streamline 
applications data management is a strong driver toward self -documenting data 
sets. The Global Positioning Satellite (GPS) system (GE 3) is based upon on- 
board navigation. To completely realize the advantages of these approaches, 
it is essential to determine the precise location of the Space Station and 
other satellites or platforms. Some of the problems and approaches to 
determining definitive orbit and making it available on-board have been 
documented in previous studies (Graf 1, Graf 2). To be autonomous, these 
functions must either be on-board or be performed as slave functions to the 
on-board system. 

1.5.5 ON-BOARD COLLISION DAMAGE AVOIDANCE 

The large cross sectional area and the indefinite lifetime of the Space 
Station will greatly increase the potential of damage from collision with 
satellites, meteorites, and particularly space debris (IEEE 2). The nature of 
the Space Station may make it more cost effective, and certainly safer for its 
inhabitants, to employ sophisticated subsystems to reduce the probability of 
collision and to avoid ensuing damage. The primary concern is to avoid 
collision with the small, out of orbital plane debris which are not tracked by 
NORAD or other such tracking systems and whose data is not available in 
existing bases. The techniques employed to sense collision courses, maneuver 
the station to change orbital plane to avoid collision, to change attitude to 
minimize damage and protect critical subsystems, or the countermeasures 
required to destroy with lasers or to sweep up the debris with remote 
vehicles, do not fall under the auspices of the data system. However, the 
data system should have the capability to receive pertinent collision data, 
process the data to determine course of action, (to maneuver, shut down 
critical operations, et cetera) and provide warning and safing information to 
the crew and subsystems. 
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1.5.6 SHIFT IN EMPHASIS FROM RELIABILITV TO AV/A I LAB I L I TY 

The long term, manned presence In space calls for a change In the data system 
operational philosophy. It Is no longer necessary, practical or cost 
effective to operate for years without a failure being evident to the crew. 
With a shift from real time fault tolerance toward availability, the 
operational functions need to be classified according to criticality 
properties. Those are I) the length of time the functions can be suspended, 
2) which functions muit fall operational, and 3) which functions may fall 
safe. Then, fault detection. Isolation, and repair assistance become 
Important. In this environment. It may be better to have controlled failures 
and a well planned maintenance program than to burden the system with mu Itlple 
redundancies that mask failures and automatically replace failed units In a 
real time mode such that the exact system state cannot be determined. 

1 . 5.7 ON-BOARD software UPDATE 

The long term, manned presence and changing mission mix will require changes 
In system configuration, both hardware and software. The mode of operation 
during these changes must still be determined. It is expected that they 
generally will be accomplished while the remainder of the system continues to 
function. This represents a marked change In spacecraft philosophy and 
requires special planning during the early design phases. 

1.5.8 on-board data analysis 

The Space Station with Its complement of sensors and personnel will be an 
Information acquisition facility.' Implicit with the near real time work 
planning and processing selection is the need to obtain feedback about the 
information being acquired. This dictates the requirement for on-board data 
analysis In a quick-look mode. This would require an emphasis on flexibility 
and data base access. Performance requirements will be driven by overall 
response time. The sizing of the system to provide this on-boc: d analysis 
capability need not be so large as to replace the ground system for normal 
operational processing. However, this is an option for future trade-off 
analysis should the resulting data reduction and communication requirements 
significantly reduce life cycle cost. 
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1.5.9 DIRECT BROADCAST TO USERS 

The characteristics of the Space Station acquired data and the acquisition 
process favor direct communication to users under certain conditions. The 
Space Station will effectively remove some of the constraints such as power 
and weight that are currently limiting data acquisition volumes. Thus, 
orders-of-magnitude Increases in data volume and concomitant communication 
bandwidth requirements may be ejcpected. Additional investment in system 
complexity to achieve this added bandwidth will be Justifiable on a case-by* 
case basis. In this environment, overall system optimization tends toward not 
upgrading the total communication system (relay satellite, communication 
ground acquisition station, et cetera) but only for the link segments 
required. The Space Station will also be a more heterogeneous source of data 
products with its capability to have in-place, although not necessarily 
operating simultaneously, a large variety of experiments and sensors. Again 
overall system optimization favors a restricted case-by-case approach to the 
driving communication requirements. Direct communication to users is a viable 
approach because in many cases the acquired data is of interest only to users 
In the coverage area where direct communication is possible. This eliminates 
the need for relay satellites for those high bandwidth communication 
applications. 


SECTION 2 
CONCEPTS 


The notion of a data system concept carries a multitude of connotations. The 
person expecting a concept to be complete from end-to-end with all 
incompatibilities resolved can be disappointed when the concept involves only 
a single aspect of implementation. On the other hand, most trade-off analyses 
involve pieces of the whole. Within the context of this study both extremes 
of concept definition were used. The abstract concepts include the end-to-end 
system but only at a high level. From these abstractions came the more 
defined data system concepts. Both the concepts of abstraction and 
instantiation will be expanded upon in this section. 

2.1 DATA DEPENDENCY DIAGRAMS 

As a means of functionally partitioning the data system, the data products of 
each function were identified and described. The description included their 
structure, size and make-up, their !;(ource, and their use. From these 
descriptions, data dependency diagrams such as Figure 2-1 were devised. 
These diagrams in turn indicate which functions can be performed in parallel, 
which functions should logically be co- located, and the data transfer 
capability required between functions. 

2.2 CONCEPTS OF ABSTRACTION 

Just as issues arise over the practicality and implementation of data system 
concepts, other concepts arise because of issues. Figure 2-2 illustrates the 
first level of concepts and how they were driven by the issues. 

2.2.1 HIERARCHICAL CONTROL 

The concept of hierarchical control is fundamental to addressing the issue of 
autonomy. it can also be supportive of the architectural issues. This 
concept is illustrated in Figure 2-3. 

The significance of this concept is that commands across boundaries provide a 
description of what is needed to be accomplished and the return information is 
a verification of accomplishment. Theoretically, once a command is received, 
the interface could be severed and the objective would still be accomplished. 
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Figure 2-2. First Level of Concepts Driven by Topics 


Intelligence, which Implies computational resources and data sets. Is 
distributed at the lower levels. This will allow Incremental growth with 
minimum system level impact. It Improves survivability by incorporating a 
degree of internal reconfiguration at the intermediate levels. The failure of 
a verification signal can be used to trigger the reassignment of the 
functional command to another unit. 

The role of man in this concept can vary according to the approach to 
autonomy. For some completely automated functions that can continue without 
manned Intervention, man will be interjected at a subsystem level. In this 
role, man is an Information source. The Information Is combined with other 
information for the automatic operation of the system. For some functions, 
the system could operate even when the inputs from man were lacking. 

2.2.2 VIRTUAL ARCHITECTURE 

The concept of virtual architecture Is illustrated in Figure 2-k. This 
concept incorporates layering. Each layer of Integration, when successfully 
performed. Is the gateway to the next layer. With such a protection scheme 
the impact of a design flaw in the new capability, or a flaw resulting from 
Its Interaction with the on-line system will be minimized. The "layering" 
from an integration viewpoint should cause a "staged activation" of the new 
function. Intermodule communications and data flows will be across specific 
boundaries. 

A clear partitioning between operational functions and mission functions is 
indicated. This is justified on the presumed greater availability and fail 
operational requirements for operational functions. Redundancy and cautious 
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Figure 2 -^. Concept of Virtual Architecture 






impletnentatiQn of modifications will be drivers for the operational systems. 
The mission systems will be more subject to change and trade-offs of fall 
operational to fail safe modes against an environment of cost and 
functionality considerations. 

A significant assumption in this concept is that the mission applications 
systems and their users will have total access to all data defining the 
operational state of the Space Station. This can be accomplished with a 
layered architecture and yet maintain absolute isolation of effects In the 
mission systems from adversely impacting the Integrity of the operational 
systems. 

The mission systems are shown with a common communication path although that 
is not Inherent In the concept. As systems would be remotely deployed (e.g., 
on outlying platforms) separate Interconnecting layers would be Implemented. 

Those mission functions that have a high degree of commonality across missions 
would be included as part of the Space Station data system facility. 
Processors, storage, human interfaces, and general use data sets are in this 
category. 

If some missions require complete Isolation, as do some of the military 
missions, completely separate components could be accommodated. These would 
be the responsibility of the mission users. 

2.2.3 STANDARD INTERFACE 

The concept of standardization of interfaces follows as an adjunct to 
implementing the layered, virtual architecture. This concept is Illustrated 
in Figure 2-5. Implicit in this concept is standardized formats. If this can 
be carried through the entire data system implementation, future flexibility 
wi II be enhanced. 

A set of standard interfaces will permit a selection of data paths tailored to 
the functional needs. Parallel and serial Interfaces of a number of data 
rates and bus width categories are desired. The definition of standards will 
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allow parallel subsystem development and future Improvement without impacting 
the overall system. 

The standardized formats will apply to signals and data. Some precedents are 
being established in the communications field with packetized messages, 
whether data or commands. This concept is consistent with the notion of self 
documented data sets. in a parallel control interface environment, the 
identifiers would be the control code lines. The length of the messages or 
data width can be variable according to the established rules or as identified 
in the header. 

The underlying objective of this concept is to assure that every interface is 
adequately defined so that the correct function of the system is independent 
of a system module having predetermined information about the presence of 

sptiicific modules, 

2.2.i» ALTERNATE CONCEPTS OF AUTONOMY 

Two concepts of autonomy that have major differences in the placement of 
burden are illustrated in Figure 2-6. Autonomous operation can include the 
Space Station ground facilities. In the one concept, complete capability for 
mission operations exists in space. The obvious penalty is the need for 
additional functions, equipment, and personnel on the Space Station. The 
corollary benefit is a reduced space to ground communication channel 
requirement. 

The alternati^ concept has an implicit interaction with the ground facility. 
Computed values would be uplinked and intermediate data products would flow in 
both directions. 

2.3 CONCEPTS OF INSTANTIATION 

A basic overall system configuration and concept which can be used to 
Implement the two categories of functions is depicted in Figure 2-7. It 
consists of separate data buses and computational systems for each class 
function with some shared memory storage. It is envisioned that the 
operations computer system would have full control over the shared storage, 
i.e., both read and write capability; while the mission computational system 
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Figure 2-6. Major Alternate Concepts 
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would have read/write freedom in only a portion of common memory with read 
only capability In the remaining portion. Some comioon shared storage is 
desirable to facilitate communications between the two basic categories of 
functions and also to allow the two systems to operate on common data bases. 
However » storage protection of data and information in the read only portion 
to the missions computer is necessary for data/ informat ion generated by and 
peculiar to the operations system. it must be available for the mission 
systems to assist in minor operational functions. 

The shared memory hierarchy (i.e.| cache, primary working storage, bulk store, 
et cetera), memory system redundancy schemes, rebooting techniques, et cetera, 
and menipry technologies to implement the select hierarchy are subject to more 
detailed trade studies. 

For economical and operational reasons such as design, development, logistics, 
and training, the data management computers shown In Figure 2-7 will utilize 
identical architectural and detailed design philosophies although the specific 
composition of a particular computer may differ from the others. This 
approach can be better understood with the aid of Figure 2-8 which shows an 
architectural concept that can be used in the computer. An overall computer 
system would consist of a variable number of processors, memories, memory 
switches, and internal memory buses. The system is highly modular to provide 
high reliability throughput (both variable) depending upon its specific 
application. The internal buses must be fast to enhance the flow of 
information between processors and memories. They would be parallel buses. 
Data buses external to the computer system which interface the various 
operation functions such as power, life support, environmental control, and 
monitoring would be serial for practical reasons. The number necessary will 
depend on the number and possible type functional mixtures, bus speed, and bus 
loading. Error coding techniques and redundancy schemes would be utilized in 
each of these buses as required to satisfy criticality and reliability 
objectives. 

Two concepts utilizing this basic system will be discussed in the following 
paragraphs. The first Is a system design where the subsystems operate 
asynchronously with the command management subsystem '*in charge" and the data 
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management computer merely a data supplier. In the second system design^ the 
data management computer Is responsible for more of the overall system control 
functions rnciuding data system managementf subsystem state control, status 
monitoring, and configuration management. 

2.3 CONCEPT I 

Concept 1 consists of subsystem functions which are essentially autonomous, 
i.e., no single element within the system provides over a I i control. However, 
the Command Hanagement System (CHS) will provide a certain degree of control 
in that it: 

o arbitrates conflicts between subsystems, 

o checks constraints before issuing commands to make sure there are no 
conflicts, and 

o generates lower level commands to the subsystems. 

Except for these control functions of the CMS and the passing of information 
between them, the subsystems are functionally independent of one another. The 
system is stochastic and asynchronous in that the operation of each subsystem 
cannot be predicted with certainty at any given time. 


Figure 2-9 provides an overview of Concept 1 and F.igure 2-10 provides a more 
detailed description, it shows the various inputs to the system; the internal 
and external communications, the commander, and chief operations officer. 



Figure 2-9 • Overview of Concept I 
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Figure 2-10. Operations Data Hanagement System 















These Inputs will be interfaced to the subsystems thruuah a multiply redundant 
data bus. The subsystems will porform their functions asynchronous ly» with 
the command management subsystem having responsibility for orchestrating the 
other systems. The data management computer will serve mainly as a data 
supplier providing the subsystems with the common operational data. 

A scenario illustrating this concept might be as follows. An experiment 
informs CHS that a change in attitude is necessary. The CMS checks all other 
subsystems to assure there are no conflicts and then generates the necessary 
descriptors to relay to the attitude subsystem. The attitude subsystem* In 
turn* takes the descriptors to the level of actually executing the maneuver* 

In a hierarchical partitioning of functions according to response time 
criticality, some were allocated to a support subsystem. Figure 2-11 shows 
the operations support subsystem. This subsystem contains Its own dedicated 
computer and data buses as required. This subsystem interfaces directly to 
the serial buses of the operations data management computer system. 

A scheme for reducing the burden on the operational and mission primary 
computational and data systems is shown in Figure 2-12. The flow of auxiliary 
or utility data between the major subsystems within the overall system* both 
operational and mission function* is acconmodated. It allows direct 
communication from subsystem to subsystem without involving the various other 
components within the overall system hierarchy. The number and type of 
utility buses which should be made available are subject to trade studies and 
the specific definition of the Space Station data management system 
configuration selected. It has been included in this concept because It 
provides the system with a great deal of flexibility and utility and is 
expected to lead to ease of system operation. 

Similar to Figure 2-10 on the operations side, Figure 2-13 shows the mission 
functions of subsystems interfaced to the mission function data management 
computer system through a multiplicity of serial data buses. From a 
conceptual point of view and technical design considerations, the two 
functions (operational and mission) are identical; they differ only in the 
types of functions, bus loading, function consolidation, et cetera. 
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Figure 2-11. Operations Support Function Subsystem 
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Figure 2-13. Mission Data Management System 

















Figure 2-H shows a typical mission specific subsystem and gives more details 
of what may be required in the mission control subsystem* 

2 . 3.2 CONCEPT 2 

Concept 2 considers a different approach to the Space Station data management. 
The major variations of Concept 2 from the first concept are: 

o Reallocates functions for simplification and economy 

o Illustrates implementation for operations data 
management system (ODHS) 

A block diagram of the system Is shown in Figure 2-15. The figure shows 
several of the Station's subsystems and suggests ways in which the operations 
function may be broken down or combined. For example, the navigation, 
collision avoidance, and orbit determination and maintenance function have 
been combined into a single subsystem becausf* of Interdependence in functions 
and physical components. Maintaining or changing trajectory entails inputs 
from navigational sensors to determine orbital ephemerides. The collision 
avoidance function likely will use information from both the navigation 
sensors and special collision avoidance sensors to solve the orbital mechanics 
problem and ascertain If an impact with Space Station is probable. 

Figure 2-16 shows a simplified block diagram of the navigation, collision 
avoidance, and orbit subsystem. The subsystem consists of an interface to the 
primary station operations data bus, an internal redundant subsystems bus, 
interfaces to the navigation and collision avoidance components and a 
subsystem computer. External inputs flowing into the subsystem consist of 

data from navigation and collision avoidance radars, lasers, and other 
sensors. The independent subsystem computer is used to determine the orbital 
parameters of both the station and incoming targets and to control the slewing 
of the navigation and collision sensors as required. To effect orbital 
change, this subsystem must communicate with the attitude and control and the 
propulsion subsystems through the Station's operation bus. In addition, 
considerable information will flow between this subsystem and the display and 
control and the data base operations subsystem. 
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Figure 2-U. Mission Control Subsystem 
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Figure 2-15. Operations Data Mana^gement System 
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Figure 2-16. Navigation, Collision Avoidance, Orbit Subsystem 



Unlike Concept 1, Concept 2 provides a display and control subsystem. This 
subsystem provides the link between any station Inhabitant, the subsystems and 
the operations data management computer. It is the "man-machine" interface. 
The commander, chief operations officer, and crew functional interfaces are 
provided in this subsystem. Figure 2-15 does not imply that displays, panels, 
control switches, keyboards, printers, audio inputs and outputs, or other 
input/output devices and components are centrally located. It is assumed they 
are distributed throughout the Space Station core module and communicate 
through internal buses. 

The environmental and life support functions have been combined in Concept 2 
because of the similarity which exists in these operations. 

Although in Concept 2, operational functions have been considered and grouped 
differently than In Concept 1, the major difference lies in the operational 
control ef the data management and in the functions performed by the 
operations data management system computer (ODMSC). It should be noted that 
the operational functions of the Space Station have been distributed as much 
as possible to the subsystems. Each subsystem contains its own computational 
unit and functions as independently as possible of the other subsystems. 
Unlike Concept 1 however, the ODMSC schedules, directs, assigns, coordinates, 
integrates, monitors, and orchestrates the activities of the subsystems (and 
missions as required). Although the concept cannot in any reasonable sense be 
considered as "centralized control" since so many functions (as many as 
possible) have been relegated to the subsystems, it provides for coordination 
and orchestration within the operations data management system. Figure 2-15 
shows some of the functions which may be accomplished in the ODMSC. Unlike 
Concept 1, which contained separate subsystems for operations support, 
internal communications, and subsystem performance analysis, these functions 
are accomplished in the ODMSC in Concept 2. Although Figure 2-15 provides a 
data base operations subsystem for the bulk of the data base functions, it is 
possible that some (limited) functions can be most efficiently handled in the 
ODMSC. it also appears that subsystem status, performance analysis, 
configuration management, et cetera, should reside in a central common source. 
While control of the data management system in Concept 1 may be considered a 
stochastic process, that of Concept 2 is of a more deterministic nature. 
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However, neither concept employs control techniques which can be categorized 
entirely In one of these pure forms, it Is really a matter of degree and the 
two concepts are considered to lie at different ends of the spectrum. 

As in Concept I, it may be desirable to break the internal operations 
function, which provides multiplexing, sequencing, command, and controls 
directly to the operations subsystems and mission data management, into a 
separate subsystem. This option is indicated by the dotted lines in Figure 2- 
15 which show the internal operations function as a separate subsystem. The 
details and approach which could be employed are very similar to that shown in 
Figure 2-12. 

2.3.3 COMPARISON OF CONCEPTS 1 AND 2 

A brief summary of the characteristics and attributes of the two concepts is 
provided in Table 2-1. 


Table 2-1. Summary Comparison of ODMS Concepts 


CHARACTERISTIC 

ODMS CONCEPT 1 

ODMS CONCEPT 2 

CONTROL PHILOSOPHY 

STOCHASTIC 

DISTRIBUTED 

ASYNCHRONOUS 

DETERMINISTIC 

CENTRALIZED 

SYNCHRONOUS 

RELATIVE NUMBER 
BUS CONNECTIONS 

MODERATE TO HEAVY 

LIGHT TO MODERATE 

RELATIVE BUS LOADING 

MODERATE TO HEAVY 
RATES 

LIGHT TO MODERATE 
RATES 

ODMSC RELATIVE 

COMPUTATIONAL 

CAPABILITY 

LOvif TO MEDIUM 
THROUGHPUT 

MEDIUM TO HIGH 
THROUGHPUT 

ODMSC FUNCTIONS 

1. DATA MANAGEMENT 

2. CONTROL INTERACTIONS 
BETWEEN OPNS & 
MISSION FUNCTIONS 

1 . DATA MANAGEMENT 

2. INTERNAL OPNS 

3. OPERATIONS SUPPORT 

h. SUBSYSTEM PERFORMANCE 

5. COMMAND MANAGEMENT 

6. STATE AND STATUS 
MONITORING 

7. SUBSYSTEM 
CONFIGURATION CONTROL 
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SECTION 3 
ANALYSIS 


The analysis of the alternate concepts will of necessity be at a high level 
pending more detailed development. Since the purpose of this study is to 
concentrate on Innovative approaches that may uncover technology needs, the 
effort In this section will be directed toward those concepts that have not 
been previously applied to spacecraft. An interactive relationship exists 
between the conceptual development and the analysis. At each succeeding 
level, alternatives of implementation arise and are subjects for trade 
studies. At some point, an option is selected for further refinement of the 
concept. In this section, a high level qualitative assessment of the 
alternate concepts is presented. 

3.1 RELATIVE COMPARISON OF CONCEPTS 

Each concept pref«<i;ited in Section 2 has some inherent advantages that will be 
addressed In a summary manner as a beginning of the analysis. A list is 
presented in Table 3-1. 

Table 3-1. Relative Advantages of Alternate Concepts 
Advantages for Concept 1 

o Major Partitioning by Criticality of Functions 

o Modularized to Extent Non-Traditional Functions are Separate Modules 
o More Hierarchically Connected 

/Advantages for Concept 2 
o Fewer Subsystems to Connect on Bus 

o More Reserved Processing Capability Available for Critical 
Functions by Implementing Priority Load Shedding 

o Operations Data Bus Less Burdened with Data Flow 


3.1.1 CONCEPT 1 PARTITIONING 

The major partitioning of functions by criticality offers some advantage for 
Concept 1. This permits a concentration of attention to reliability, 
redundancy, and fault identification for those functions requiring it. The 
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relaxation of requirements for other segments of the data system may permit an 
overall simplification. 

3.1.2 CONCEPT 1 MODULAR iZATi ON 

The high degree of modularization of Concept 1 allows the non-tradltlonal data 
system functions to reside in nearly autonomous modules. This should 
facilitate the development of a system initially along more traditional 

approaches and then grow to greater functionality by adding modules. In this 
concept, command management, subsystem performance analysis, collision damage 
avoidance, the various support functions, communications channel management, 
and maintenance assistance are each separate modules. These functions are 
presently ground activities. 

3.1.3 CONCEPT 1 HIERARCHICAL CONNECTIVITY 

Concept 1 is hierarchically connected. This offers advantage for fault 
isolation and correction. it also has some advantages for distributing 

control among smart system elements. 

3.1.4 CONCEPT 2 BUS CONNECTIONS 

Concept 2 has fewer components connected on the bus. This has inherent 

savings in component count and Inherently better reliability. With fewer 

devices, greater attention can be devoted to redundancy and fault tolerance. 

3.1.5 CONCEPT 2 PROCESSING RESERVE 

By concentrating more functions In the data management computer in Concept 2, 
a greater reserve computing power is available for critical functions. This 
follows from the assumption that the same number of processors is required in 
both concepts. Then some of the support functions could be temporarily 
suspended to make processors available in a contingency mode. 

3.1.6 CONCEPT 2 DATA BUS LOADING 

The concentration of functions in the data management computer in Concept 2 
reduces the need for data movement on the data bus. This will reduce the bus 
bandwidth requirement and permit resources to be allocated for greater 
redundancy. 
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3.2 ARCHITECTURE ANALYSIS 

The basic approach and concept employed in the Space Station data management 
system is that there is a hierarchy of bus and computer structures so that the 
overall objectives and tasks can be defined and broken down into succeedingly 
smaller tasks. The lowest level which is concerned with and dedicated to 
accomplishing a specific task is relegated to a subsystem or possibly even a 
component (e.g. , in determining the desired attitude of the station or by 
accepting a desired orientation from another internal or external source, the 
subsystem (or component) can issue a command or a sequence of commands to 
effect the desired change). 

In order to be cost effective, a standard approach and architecture must be 
developed and utilized at the various levels within the Station's data 
management hierarchy such that common elements can be mixed to achieve the 
objectives of that particular level. Principal variables at each level are 
throughput and criticality/reliability, and a method has to be developed so 
the overall system and specific subsystems can be readily configured to meet 
these objectives. A paramount ri>quirement in both the overall system and 
subsystem design is that faults and failures be detected and isolated. 
Defective elements can then be either automatically or manually replaced. The 
discussion which follows deals primarily with the problems of achieving 
variable throughput, reliability, and trade-offs thereof, and in fault 
detection and isolation in a computer architecture which can be employed at 
any level within the hierarchy. However, the same principles and concepts 
apply to the networks or buses which are used to interconnect the levels 
within the hierarchy. 

Figure 2-8 showed a standard computer architecture which employs a variable 
number of processors, memories, input/output units, buses, et cetera. The 
number of processors used, for example, does not have to equal the number of 
Input/output units. The objective is that the number of processors, memory 
units, and input/output units can be tailored for a particular level to meet 
the throughput and criticality/reliability objectives of that particular 
subsystem. The basic problem is to develop an architectural concept which can 
be designed to satisfy these objectives. 
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The crux of the problem lies In determining when a malfunction has occurred, 
In planning strategies and taking corrective actions, and in providing and 
scheduling resources to meet the overall objectives. Hardware, software or a 
combination of techniques can be utilized. The choice depends upon the 
objectives and constraints such as the necessity to mask faults (in real 
time), system response and timing specifications, the physical attributes of 
power, weight and volume, et cetera. One method which employs a combination 
of hardware and software techniques is illustrated in Figures 3*1 and 3*2. In 
this approach, there is a kernal (prime) activity which is running and a 
monitor (essentially a replica or a condensed version of the prime) activity 
which is performed concurrently. Signals ("heart beats") pass back and forth 
between the kernal and monitor indicating that the two processes are obtaining 
similar results or that they are synchronized. In the simplest form, the 
monitor may be a watchdog timer which expects to receive specific signals from 
the kernel within prescribed time frames. Should either the kernal or the 
monitor fall to receive a "heart beat," then decision logic must be Initiated 
to determine wherein the problem lies. Decision strategies and logic are 
shown in Figure 3*2. A basic question is that if this approach is takep, at 
what level in the hierarchy should it be applied? 

It is also possible to rely heavily upon hardware to detect and isolate 
failures as well as mask faults within a system. This technique is usually 
employed for real time operations where false outputs or any down time cannot 
be tolerated. 

The primary concern in the Space Station data management system architecture 
is to define the objectives of the system and to devise a concept which meets 
these objectives within the known constraints. A major goal of the Space 
Station is developing a basic architectural approach that exhibits the 
following characteristics: 

o can be used at the various levels in the station's data management 
hierarchy, 

o provides variable throughput, 

o allows ready fault detection and isolation to optimize system 
aval labi 1 ity, and 

standardizes elements to minimize life cycle costs. 


o 
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Figure 3“1* The Concept of independent Kernal and Monitor Tasks 
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Figure 3“2. A Fault Tolerant Operating System 




3.3 AUTONOMY ANALYSIS 

Since the Space Station will be a long term national asset» serious 
consideration should be given to the various modes of operation involving the 
interpi^sy between the ground, the crew, remote stations, freeflyers or 
satellites, and the operational systems on-board the Station. Due to the 

indefinite lifetime of the Station which emphasizes the need to minimize 
operational costs and the fact that there will be times when the Station is 
unattended, some degree of autonomy is required. In fact, a major objective 
and driving function in the design of the data management system is autonomous 
operations. There are several degrees or definitions of autonomy which are 
applicable to the Space Station. These are: 

o The Space Station and personnel can operate for extended periods 

without benefit of ground support or other non Space Station 
systems. 

o The Space Station system, including the ground segment, can operate 
for extended time without support from other non Space Station 
systems . 

o The Space Station in orbit can operate without human intervention, 

continuing automatically to acquire data and perform its function. 

o The Space Station system, including both the in-orbit and ground 

segments, can operate automatically without human intervention. 

There are many motivations for autonomy such as peak performance, greater 
flexibility, and lower life cycle costs. Methods of achieving these goals 
i nc I ude : 

o Reducing the number of operational personnel required. In space the 
number must be limited. On the ground, the indefinite lifetime 

multiplies the effect of operational personnel on lifetime costs so 
significant investment in an autonomous (not requiring humans in the 
loop) system can be justified. 

o Increasing mission success probabilities by reducing reliance on 
ground support. This is especially pertinent for military missions. 

o Freeing Space Station inhabitants from the operational aspects of 

the Station so that they may devote maximum time to scientific 
observations and experiments. 

Trade-offs and definitions in the varying degrees of autonomy are necessary 
and are expected to be used to establish groundruies and guidelines for the 
eventual design of the Space Station's data management system. 


3 . ^ DATA BASE ANALYSIS 

Providing the date where and when it is needed is the prime objective of the 
data base system. This system includes the storage medium and the update and 
across facilities. 


The fcti'owing assumptions have been made concerning the data base: 

o Separate data base partitions wi i I be provided for the operations* 
oriented and mission-oriented functions. 

o Processed data will be stored in the data base by function. The raw 
data wi I i serve as backup. 

o Data storage and file management will be provided to support both 
real time operations requiring immediate data access and for storage 
of archival data requiring occasional access. 

o The DBMS will provide parallel redundant storage for data that 

cannot be regenerated. 

o The DBMS will provide staging capabilities such as ground/space, 

operation/ mission^ and function/function (e.g. collecting data for 

docking from orbit and attitude data bases). 

o Security of the data will be effected by access privileges, 

encryption, non-disclosure agreements and policy regulations. 
Military security will be effected by separation of subsystem 
components and black boxes. Military security will not encompass 

data m^cessary to the operation of the Space Station. This 
operational data will be available to rill users. 


There is a need to provide multiple access to a distributed, heterogeneous 
data base. This may be accomplished by having a portion of the data base on 
the ground and staging It to the Space Station as required. Staging involves 
loading necessary data bases into readily accessible memory prior to when it 
is needed. Access methods, natural language query, and other technological 
advances must be considered. 


The idea of a self-organizing data base is discussed in more detail in Section 
A. 5. This is an artificial intelligence approach to access data from a large, 
distributed data base over a computer network. 


3.5 LOGISTICS ANALYSIS 

The data system will perform a major role in logistics and logistics 
management. Because of the indefinite lifetime and manned presence, the 


entire operational philosophy will be different from previous spacecraft. 
Built-in fault detection, isolation, and manned repair will be normal. Spare 
parts management will be a significant role for the data system* The whole 
reliability requirement will also change with an emphasis on availability. 
The need for man to effect repairs has been emphasized. 

3.5.1 DATA SYSTEM COMPONENTS 

As an aid to analysis of the data system invoivement in logistics, selected 
components from Concept 1 are shown in Figure 3”3- Each of these will have 
some involvement in the operations or manipulation of logistics data. The 
basic question is whether logistics should be managed from the ground or the 
space segment. With either approach, a significant function of the ground 
facility will be to assist in performing the logistics function. 

Logistics will Involve the supply and maintenance of every element on the 
Space Station. These elements include consumables, supplies, spares, and 
mission products. Depending upon the maintenance philosophy, line replaceable 
units (LRU) may be returned to the ground for repair. For space processing 
missions, the transportation and tracking of those products will impose a 
significant load on the ground support system. 

Because of the design philosophy imposed on the concepts, the spaceborne data 
system will exhibit sufficient autonomy that no part of the ground system is 
deemed critical. Therefore, integration of mission driven logistics with 
operation logistics is acceptable. 

3 . 5.2 FLOW OF LOGISTICS DATA 

Logistics data may originate from many components of the data system. On the 
mission side, the mission management subsystem will have interfaces to update 
data files of logistics information. The files will physically reside on the 
mission mass memory. The maintenance of these files will be performed by the 
mission support computer. 

Logistics data may also originate from the operation components. The 
preparation of logistics data files for transmission to the ground will be 
performed by the operations support computer. It will maintain the up-to-date 
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files on the mass memory. These files will include mission data. That data 
would be passed to the operations support computer via data requests to the 
operation data management computer. That computer w^duld direct the mission 
data management computer via the shared memory to provide the data to the 
shared memory. The mission data management computer would obtain the data 
from the mission support mass memory in a read only access authority. 

Other logistics requirements would be determined by the operations support 
computer from data provided by the operations and maintenance subsystem and 
the subsystem performance monitoring subsystem. 

The operations support computer will keep up with logistic data on the 
consumables such as fuel, oxidizers, gases, and other resources that are 
automatically consumed during the normal function of the subsystem. Included 
is data on supplies, such as food, and experiment expendable items that have a 
scheduled consumption and replacement cycle. Other data includes the nature 
and quantity of the spare parts. It includes those on-board the Space 
Station, in ready supply locations, on other vehicles such as shuttles, and 
available for cannibalization from other subsystems. As part of logistics 
management performed by the operations support computer, supply levels are 
monitored and resupply is scheduled when a predetermined level is reached. 

3.5.3 LOGISTICS ALTERNATIVES 

As indicated, some of the logistics management, especially the scheduling of 
resupply, may be performed on the ground. The principal argument for 
performing the function on-board the Station is that the Space Station is 
responsible for its own mission scheduling. Therefore, any logistics impact 
as well as any anticipated mission impact on logistics requirements can be 
more accurately forecast. 

Other functions frequently included in logistics under the terminology 
"Integrated Logistics System" or ILS include training, maintenance, and 
configuration control. These functions will be incorporated Into the Space 
Station data system. Many, such as crew training, crew skills inventory, on- 
board maintenance assistance, and configuration are needed interactively on- 
board. Should it be determined to perform the management and analysis on the 
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ground, the data would need to be accessible in near real time by the on-board 
systems. For some of the more sophisticated training and maintenance 

concepts, such as using interactive color video displays, a significant 

reduction in communication requirements can be achieved by performing the 
functions on-board. 

3.6 COLLISION AVOIDANCE 

There is a high probability that the Space Station will be impacted by an 

object at some point in time because of its large cross sectional area and 
long duration. Satellites, either active or dead, meteorites, and space 

debris or Junk are examples of the type of objects likely to be encountered by 
the Station. Satellite ephemerides may exist in ground based data systems and 
be available to the Station. However, sporadic meteors and meteorites by 
definition are unpredictable; little or no effort has been made to keep track 
of the numerous small to medium sized objects comprising space debris. 
Objects approaching the Station from an out-of-orbital plane position are of 
most concern. These may be approaching the Station from above, the sides, or 
the front. The earth shields the Station from below and the relative velocity 
of an object approaching from the rear would probably be small. 

The destruction potential of an object to the Station depends upon its 
momentum relative to the Space Station; i.e., its mass and relative velocity. 
Depending on the Station's structural materials, design, and construction, the 
Station may be able to withstand impacts from very small objects. Collision 
with objects which can result in severe structural damage or the loss of 
critical components must be avoided. 

Given a sufficiently long period of observation of an object, it is possible 
to avoid collision with only minor changes in either station velocity (fore or 
aft) or direction (lateral or vertical). The distance, P, through which the 
Station can be moved in time, t, when given an acceleration. A, is P«iAt . 
(Morrell 1). Thus, the longer the observation time, the lesser the 
acceleration or energy required to move the Station out of the object's path. 

Figure 3-4 shows the miss-distance in meters at time intervals of five seconds 

2 

using A-l/100 meter/sec . This figure shows that the best solution is to make 
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small changes early. A change in fore or aft acceleration of the Space 
Station would be difficult to achieve; therefore, the lateral or vertical 
acceleration maneuver would be the best approach. To ensure that minimum 
maneuvering energy is used, two factors are of importance; that the miss- 
distance is small and that imminent collision be known early. The challenge 
Is to detect those objects at sufficient distance to allow time to avoid them. 

3.6.1 OBJECT DETECTION 

The larger objects in space are tracked by ground radar and their trajectory 

can be provided to the Space Station. It is the small objects that are of 

Interest to on-board detectors. Because of the narrow beam width used In most 

tracking radars, a small unknown object is difficult to acquire. (Berkowitz 

1) lists the characteristics of the AN/FPQ:-6 and AN/TPQ-18 radars. Using this 

2 

information. Figure 3-5 shows the object size in meters as the radar maximum 
detection capabilities. These radar sets have range accuracy capabilities of 
less than one meter on a well defined object. But the angle accuracy is 
between 0.1 and 0.05 meter radians. This would be an error of 20 to 50 
meters. It is possible to improve these figures using special smoothing 
techniques. Reaching the goal of two to five meters is questionable because 
of random errors. A range of 65 to 70 miles as a requirement would allow the 
Space Station personnel time to make the necessary calculations to determine 
whether a collision was imminent and take collision avoidance action if 
necessary. This short range radar would allow tracking of objects with a 
closing rate of t40 meters per second. 

3.6.2 SOME RADAR PARAMETERS 

There are approaches to developing a system to meet the Space Station 
requirements for detecting objects at a range of 65 to 70 miles. The system 
may use radars or lasers. A typical pulse radar system will be developed here 
since radar is more mature. However, the resolution may be marginal. The 

selection of a frequency or band is a problem because of the many pros and 
cons to be evaluated in making the selection. To ensure the availability of 
hardware and test equipment, an X-band system would probably best meet the 
Space Station requirements. A transmitter frequency of 1200 MHz was selected. 
A noise budget figure of 8 db would be achievable. Using the 1200 

3-13 


ORIGINAL PAGE 18 
OP POOR QUALITY 





ORIGINAL PAGE IS 
bF POOR QUALITY 

HHz frequency and a two meter parabolic antenna, the antenna gain would be kS 
db. A pulse duration of two microseconds was assumed. Another assumption is 
that the transmitter would have a peak power of 50 KW. 

Using the above parameters, the radar system would be capable of detecting and 
tracking a one square meter target at a range of 15^*5 kilometers and a 0.5 
square meter target at 125.5 kilometers^. Table 3’2 shows the relationship 
between the target sizes and distances at which the object may first be 
detected. 


Table 3-2. Collision Avoidance Radar 


TARGET SIZE 
(METERS2) 

RANGE 

(KILOMETERS) 

+6db. 

(Kl LOMETERS) 

1.0 

15^.5 

212.4 

0.5 

125.5 

180.2 

0.2 

99.8 

135.2 

0.1 

85.3 

117.5 

0.05 

70.8 

117.5 

0.02 

56.3 

80.5 

0.01 

^♦6.7 

67.6 


A number of changes could be made to this radar system to improve performance. 
The receiver performance could be improved by the use of a matched filter 
system, analog or digital integration, or a form of correlation detection. 
These approaches could be used to increase the radar system's range or reduce 
the transmitter power requirements. A trade study would be to optimize the 
radar system as to system weight, antenna size, frequency, and tracking range. 

3.6.3 COLLISION AVOIDANCE SUBSYSTEM 

A data management scheme for accomplishing the collision avoidance function Is 
described briefly here and is shown In Figure 3-6 along with the other 
operations data systems and functions which are associated with the detection 
and collision avoidance subsystem. it is anticipated that special sensors 
such as radars and lasers would be required for target detection and tracking. 











OPNS 6 Miss ION SUBSYSTEMS 


F 



Figure 3“6. Collision Avoidance Subsystem and Interactions 
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They would be located in positions to provide detection of objects approaching 
the Station from the top, front, and each side? protection from behind 
(trailing edge) or below (facing earth) the Station probably will not be 
required. The sensors may be of the scanning type requiring slewing which 
would be accomplished by the collision avoidance subsystem. The collision 
avoidance sensors may be used either separately or in conjunction with those 
employed elsewhere, e.g. in rendezvous and docking* For larger objects which 
ar*e tracked from ground based stations, ephemeris information enters the 
system through external communication channels and is routed to the collision 
avoidance subsystem computer. With Inputs from special collision sensors on- 
board, rendezvous and docking or other on-board radars, ephemeris data from 
the ground or other external sources, and from data base or catalog 
information residing in its memory, the collision avoidance computer 
determines if a collision is imminent. If it is, the computer essentially 
takes control of the Station by putting the various operations and mission 
subsystems in the desired state, either through individual buses emanating 
from the internal operations subsystem or through normal communications on the 
operations data bus. The operations data management computer, if not a part 
of the collision avoidance function, is at least made aware of the situation. 
Communication with the attitude control subsystem is necessary to orient the 
Station and with the propulsion system to change the Station's trajectory. 
Should other actions be required, such as the destruction of the approaching 
object, the collision avoidance subsystem would serve to close the loop 
between the sensor inputs and the impending action. 

3.7 SOFTWARE ANALYSIS 

The potential impact of software, especially software maintenance, on the 
operating Space Station is enormous. Software has been estimated (or accused) 
of accounting for 80 percent of the life cycle cost of large systems with 
embedded computers. The concern for software, both cost and errors, is 
emphasized by the U.S. Department of Defense (DoD). About 197^, DoD realized 
that it was spending too much on software. It carried out a detailed analysis 
of how costs were distributed over the various application areas and 
discovered that over half of them were directly attributed to embedded 
systems. This led to the development of Ada, which is a DoD language that has 
many features desirable in Space Station. However, before any discussion of 


language and Its analysis can be undertaken» the broader Issue of software 
must be addressed* 

3*7.1 PAS 1C CONCEPTS 

In the most basic sense, computer software permits a real time modification to 
a digital output vector. This output vector may be representative of a 
numeric value or data, it may control some electronic functions, or it may be 
converted to some analog representation. The sequence by which the transfer 
function from Input vector to output vector is altered is the software 
program. The way this software program is put together is a language. The 
sequence of steps Is a procedure. 

Although software and hardware can in theory be separated from the hardware 
implementation, and there are strong arguments in favor of so doing, there is 
a defined relationship, or binding, sometime during the process. The method 
of establishing the procedure of a language is strongly associated with its 
implementation. 

3 . 7.1.1 Control Concepts 

Most language control is based upon the use of a program counter to determine 
the next executable action. This is commonly referred to as a Von Neumann 
architecture. This Von Neumann model is sometimes classed as the notion of 
sequential execution. Within this model, several concepts of transferring 
control across module boundaries have been implemented. From the simplest 
structure of the single procedure with all control effected by branch 
instruction, layered systems have evolved with well defined protocols for 
control transfer. The problem of conceptual management of complex control 
schemes was recognized and attempts to modify the conditions led to a movement 
to banish GOTOs. Some concepts for Implementing logical control Implicit Irt 
algorithms are implemented with such statements as "IF THEN” and "WHILE.” 
With the transfer c-f control across module boundaries, new environments are 
encountered, each wHh possibly its own binding. The establishment of a 
hierarchy of call procedure formally assures compatible environments, even if 
initialization is requiredii This is sometimes termed context switching. 
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Another variation among languages in implementing control concepts is the 
notion of iterative and recursive. Generally^ an action-oriented language 
like FORTRAN that may use the same algorithm over and over again will be 
iterative. DO loops are iterative. Other languages such as LISP are 
recursive and permit modules to call themselves or other modules that may 
later call them. 

As control is passed among modules^ there is a need to transfer data across 
module boundaries. This is sometimes referred to as imported values, such os 
parameters, or exported values. Two approaches are implemented, one Is to 
provide a copy of the data and the other is for modules to share the same 
data. An object is said to be accessible from an identifier if there is a 
chain of references, called an access path, from the identifier to the object. 
Two identifiers which can access the same object are said to be sharing that 
object. If an object shared by two identifiers is modified by an access path 
through one of the identifiers, It affects the value seen by the other 
identifier. This is called a side effect. The management of side effects is 
one goal of choosing a language that aids program verification. 

As hardware becomes less expensive and greater concurrency of processing is 
effected, the problem of controlling side effects will increase. Models other 
than Von Neumann are thought to be more suitable for distributed computing. 
John Backus, a software consultant at the IBM Research Laboratory in San Jose, 
California, and one &f tfit# creators of the programming language FORTRAN, says 
the first step Is to design nojiD-Von Neumann languages; then computer designers 
will see how to build non-Vdn Neumann machines. Alternatives to Von Neumann 
languages include functional programming and models termed data flow systems. 

3. 7-1*2 Non-Von Neumann Model s 

Functional programmirig (FP), to oversimplify the concept, uses two strategies: 
1) The elimination of the Heart of the bottleneck in Von Neumann programs — 
thi "assignment" statement, which refers to arithmetic expressions and to 
storing fata in memory and fetching! it back; and 2) The introduction of 
mathemft'.csl functions, which are functions of functions and do not refer to 
specific variables, therefore, FP programs are not limited to operating only 
on data In memory cells named by variables. 
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Data flow models of computation are based on a model of objects and control 
structure that is fundamentally different from that of conventional (Von 
Neumann) computers. The notion of "memory-cel I -objects" with destructive 
assignment and accessing by copying Is replaced by the notion of "object 
Streams" which flow from one site of computation to another^ and from which 
objects can be entered and removed In a f Irst-ln-f Irst-out order. The notion 
of sequential execution Is replaced by the notion of distributed execution of 
operators whenever there are operands on which the operators may act. Since 
the only effect of executing an operator is to remove operands from input 
streams and place results Into output streams, side effects are eliminated. 

The data flow mode!! Is appealing both because It eliminates side effects and 
because It provides a more direct model for many real-world applications than 
the Von Neumann model. However, progress in developing computers and 
languages which directly support data flow computations has been slow. It is 
not at present clear whether there are inherent problems In the data flow 
model or whether further research could result In acceptably efficient side- 
effect-free general purpose data flow computers. 

When the sites of a data flow system are substantial computational devices, a 
data flow system becomes a distributed computing system. The data objects 
flowing between sites of a distributed computing system are called messages. 
Distributed computing systems introduce a new set of "communication" research 
issues, including trade-offs between computing on data objects at the point 
where they reside or at the point where they are to be used^ and issues 
concerning the updating of multiple copies of data objects In a distributed 
data base. These issues are not language design issues but must be addressed 
in the development of mechanisms and languages for data flow computation. 

3.7.2 SOFTWARE ISSUES 

Within the Space Station there are going to be many needs for software. The 
operations system concerned with the housekeeping functions have a need. The 
experimenters and mission users have a need. The on-board principal 
investigators have another need, often to develop software programs in real 
time to assist in their experiments. Within this framework several issues 
must be addressed. Some are: 



o Cofmonallty of software from ground to different configurations of 
computers on-board. 

o Commonality of software as con^uter configurations change due to 
maintenance or failures. 

o Consistency of computational results as comparable software executes 
on different hardware configurations. 

o Readability - it is recognized that professional programs are read 
much more often than they are written. It is important therefore to 
avoid an overly terse notation such as in APL which; although 
allowing a program to be written down quickly; makes it almost 
impossible to be read except perhaps by the original author soon 
after it was written. 

o Programming in the large - mechanism for encapsulation; separate 

compilation and library management are necessary for the writing of 
portable and maintainable programs of any size. 

o Exception handling - it is a fact of life that programs of 

consequence are rarely correct. it is necessary to provide a means 
whereby a program can be constructed in a layered and partitioned 
way so that the consequences of errors in one part can be contained. 

o Data abstraction - extra portability and maintainability can be 

obtained if the details of the representation of data can be kept 
separate from the specifications of the logical operations on the 
data. 

o Tasking - for many applications it is Important that the program be 
conceived as a series of paraiisi activities rather than Just as a 
single sequence of actions. Building appropriate facilities into a 
language rather than adding them via calls to an operating system 
gives better portability and reliability. 

o Generic units - In many cases the logic of part of a program is 
independent of the types of the values being manipulated. A 

mechanism is therefore necessary for the creation of related pieces 
of program from a single template. This is particularly useful for 
the creation of libraries. 

o Configuration control - as the system changes the total software 

system will also change. Absolute control and traceability must be 
maintained. 

o Software management responsibility - is this too big and too complex 
a problem to be assigned to the Space Station? If so, a dedicated 
ground facility may be required. This facility may include 
simulation and various code generating support tools. 

o Software requirements - does each major system partition (e.g., 

operation, mission, mission specific, support) have needs for 
different kinds of software and language or can a common approach 
satisfy all? 
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o Programmer productivity - how important is productivity? Doe? ic'he 
need for accurate software overshadow productivity? Can the two 
requirements be satisfied by the same approaches? 

The above list contains a few of the issues that require investigation* 
Others will certainly surface during the Space Station system design. 

3*7.3 OTHER CONCEPTS 

The recognition of a link between higher level languages and increased 
programmer productivity Is fostering research into more complex, 

implementations* This is aided by the Increasing performance of the hardware 
to implement the languages. Some concepts from automata theory and artificial 
intelligence will ultimately influence future high level languages* 

The notion of binding time can be viewed from the position of automata theory. 
An object may carry a type identifier explicitly, or the type could be bound 
at compile time. In J-.he latter case, one dimension of the information vector, 
in this case type, was replaced by information in memory. The language 

remembered the type that was assigned at compile time. Taking this concept 
one step further introduces context in which information is obtained from the 
surrounding constructs, usually those preceding, but not essentially so. 

Early languages were necessarily quite restrictive in both vocabulary and 
allowable structure* Hardware was expensive and it was incumbent upon the 
programmer to conform. Now hardware is cheap and the cost of programming is 
high* Programming languages must adapt to the needs of the programmer. But 
there is still a broad gap between the richness of the language in which the 
programmer thinks and available programming languages. The natural language, 
being open and allowing for infinite differences in meaning, does not easily 
translate to the programming language. The natural language uses context to 
resolve ambiguities. Few programming languages have such capabilities. 

3*7* A SOME SYSTEM CONCEPTS 

The total data system concepts must inexorably include software. These 
include the executable on-board software, the tools to perform the 
translations from readable code with the ability to convey information to the 
programmers, and the development tools to generate and verify the code. A 
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significant ground segment to support the software element of the Space 
Station is envisioned# 

3.8 DiRECT BROADCAST 

The concept of dir^il broadcast or at least direct transmission of data from 
the Space Station to consumers on the ground must be considered. There are 
precedents with some of the earth observation satellites and ground stations 
in developing countries which have many rural earth stations. While broadcast 
communication in the sense of wide area coverage may be neither practical nor 
desirable for many situations involving the Space Station, there are many 
compelling reasons why direct communications makes sense. The implementation 
of such capability will shape the data system requirements. Once the larger 
need for direct communications is argued and the intact on data system 
requirements is quantified, additional alternatives of implementation require 
analysis. 

3.8.1. DRIVERS FOR DIRECT COMMUNICATION 

There has bee., a well justified force in the design of low earth orbiting 
spacecraft communications systems towards a concentrated relay approach using 
dedicated communications satellites at synchronous altitudes. This approach 
effectively solved the problem of maintaining nearly continuous communications 
for satellites in world coverage orbits. Satellite design could be simplified 
by reducing data buffering. Because of the bandwidths required for those 
satellites with predominantly imaging sensors, the higher frequency bands and 
complex ground receivers have been used. Thus the Tracking and Data Relaying 
Satellite System (TDRSS) with the receiving site at White Sands, NM, has 
evolved. While the TDRSS and subsequent systems are expected to serve a 
significant portion of the Space Station communication requirements, other 
factors require consideration. These factors are: 

o Channel bandwidth requirements may be one to two orders of 
magnitude greater than planned centralized communications 
capability 

o As a data generator, the Space Station will be a more 

heterogeneous source than previous satellites 

o Acquired data will have a significant local interest 

characteristic 
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3*8 *1.1 Increased Channel Bandwidth Requirement 

The Space Station will effectively reduce several constraints that limited 
total communications bandwidth requirements of earlier satellites, 
specifically weight and power. Thus there will be a capability for a greater 
number of sensors and their data taking time will not be subjected to such 
severe power restrictions. The classic example of a power restriction was the 
SAR on SEASAT. Conceivably, several active directional sensors could be 
simultaneously operating on the Space Station. With very large communication 
requirements, it Is desirable to reduce or eliminate all unnecessary links 
which includes relaying through synchronous satellites and their dedicated 
ground stations. 

3. 8. 1.2 Heterogeneous Data Source 

The Space Station will have a heterogeneous complement of sensors. it will 
act as a national resource whereby the sensors will be deployed on an as- 
needed basis. This contrasts to previous satellites with detailed pre- 
planning for the entire mission. The result is a wide variance in 
communication channel requirements that would require either a) an undesirable 
and avoidable restriction on scheduling option, or b) an excessive cost for 
communication relay channel bandwidth that would be unused much of the time. 

3.8. 1.3 Parochial Data 

Direct communication to the data consumer on the ground over the higher 
frequency channels is feasible only when a receiver is in sight. Fortunately, 
in the context of the Space Station as a national resource, the user on the 
ground with a particular need Is likely to be interested in a surface area 
near his present location. This presupposes that the global information will 
be supplied in the conventionally evolving way with established processing and 
data reduction. The data of interest to the parochial user will be the 
detailed, high information content, unprocessed, near real time data. It mity 
be surrounding ocean and atmosphere measurements or localized topography and 
weather data intended for special user processing. The data would be acquir&d 
only when the Space Station was in the particular location which coincides 
with the time when direct communication with the ground consumer is feasible. 
The required high bandwidth communication channels would be very directional 
and would permit communication with several users without interference. 



3.8.2 DATA SYSTEM REQUIREMENTS IMPACT 

The obvious requirement additions to serve the direct communications needs are 
additional antennas, scheduling, and control functions. In satellite 
communications, wide-area coverage and high antenna gain are generally 
mutually exclusive. Fortunately, for the Space Station high gain and 
directivity (with adequate pointing) are desirable. For wide-area coverage, 
the emerging technology of time division multiple access (TDMA) utilizes a 
satellite's resources very efficiently, but at a cost of straining today's 
satellite technology to improve signal gain. High antenna gain is possible 
using another emerging technology, spot-beam antennas, but their coverage is 
limited to smaller geographic areas. Now a technique has been found that uses 
TDMA to provide high antenna gain over a wide area of coverage. This 
technique is called scanning spot -beam antennas. 

Spot beams offer significant advantages in satellite .system design. They 
provide high gain and thus high effective radiated power. Using large- 
aperture antennas that might be employed in the Space Station, antenna gains 
as high as 50 db can be realized at 12 GHz. in the United States, 
particularly on the East Coast and in the South, rain attenuation is 
particularly severe, and link margins of 15 db or more might be required to 
ensure that signals exceed the system threshold for all but an hour or two per 
year. Another advantage of antenna beams is that the same frequency band can 
be reused several times within the desired coverage region. Offset Cassegrain 
antenna designs make it possible to form several essentially independent beams 
with only one large main reflector. 

Spot-beam antennas are not without problems, however. It is impossible to 
reuse the frequency band in contiguous zones, even if orthogonal polarization 
is employed. Antenna patterns cannot fit together precisely, since they do 
not have well-defined edges. As a result, more than four independent signal 
sets may be required, depending upon the degree of interference. To get 
complete area coverage with spot beams, several sacrifices must be made in 
terms of available bandwidth or antenna efficiency. Another complication 
associated with spot beams is that most satellite system designs require 
redundancy of the power amplifier to build a multibeam of the same capacity. 
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A scanning spot beam can give total coverage to the entire service area, while 
still providing the high antenna gain of a spot-beam satellite, by sweeping 
its beam in synchronism with a time-division format. The advantages are 
clear: the high gain of a spot beam Is combined with the organizational 
efficiency of TDMA. 

For complex sweep patterns involving stochastic transmission time the 
planning, scheduling; and control requirements will be significant. In 
addition, the use will basically be asynchronous and consumer initiated, which 
will require new session access protocols of a type not previously 
encountered. 

3.8.3 ASYNCHRONOUS SESSION ACCESS PROTOCOL 

The session access protocol must accommodate spatially dispersed, stochasticly 
queued channels with heterogeneous bandwidth and error requirements. To be 
acceptable to the consumer community, the ground stations must be inexpensive. 
A rudimentary protocol and the system topology is suggested below. 

f 

3.8.3 . 1 Direct Broadcast System Topology 

The burden of access and interference control would reside in the Space 
Station data system. In addition to the necessary work planning, scheduling, 
pointing, and control system, the Space Station will have multiple antennas. 
There will be a nondi rect ional , low bandwidth system for initiating access. 
Session initiation may originate from both the Space Station and any ground 
station. The possibility of over-the-horizon session initation has merit for 
additional Investigation. At least two low frequency carrier frequencies for 
full duplex session initiation operation are recommended. Thus the Space 
Station and every ground station with a requirement for Space Station initated 
sessions would continually monitor for session initiation. Each of the ground 
stations would have a fixed, highly directional antenna suitable for the 
frequency and bandwidth appropriate to the application. The number of 
frequencies deployed is subject to additional analysis. Some of the ground 
stations will have high bandwidth uplink capability also. Generally, half 
duplex operation of the high rate channels is adequate. Each ground station 
will have a unique access code. 
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3 *8. 3 >2 Space Station Initiated Session 

For a Space Station initiated session^ whether it be for uplink data such as 
obtaining in situ measurements, or for downlinking predetermined data, the 
unique access code would be broadcast to ail the ground receivers that are in 
the standby listen mode. Those specifically addressed would respond with an 
acknowledgement. This low rate communication would use the nondirectional 
lower frequency channels. The Space Station would have the burden of locating 
the ground station. Subject to additional trade study, it may be via an on- 
board trble look up of ground station coordinates or by use of a radiated 
homing signal initiated over the low rate channel. The cone of coverage of 
the ground station will necessarily be restricted. The parameters require 
additional analysis to trade-off directivity, error rates, power and total 
communication Interval. The elapsed time for high rate communication will be 
relatively short. As much as possible, the selection of frequencies and 
channel coding should precede the high rate communication time window; thus 
the necessary handshaking should occur over the low rate channel. There will 
be additional trade-offs in establishing the optimal protocol for error 
encoding, data acknowledge, and error recovery. On-the-fly error correction 
will require more bandwidth, but may drastically improve overall system 
bandwidth because shorter transmission times may be scheduled. Tight 
Scheduling would not allow room for retransmissions. The optimal protocol 
requires analysis for this peculiar environment. 

3. 8. 3. 3 Ground Station Initiated Session 

The initiation of communications from the ground stations will have different 
drivers than the Space Station initiated sessions. There will be two distinct 
conditions. In the first, the session will be a request for data acquisition 
which then must be planned, scheduled, and executed. The execution would 
involve a Space Station initiated session requiring a high rate channel for 
data delivery. The predecessor session would involve relatively small 
quantities of data and would use the low rate channel. Only in a relatively 
few circumstances, would large volumes of data be uplinked from the ground in 
a ground initiated session. Such conditions should be allowed for but not be 
permitted to drive the protocol determination. The remainder of this 
discussion will focus on use of the low rate channel. 


3-27 


Each ground station will have a unique identification code. The Space Station 
will monitor the uplink frequency for session requests. Some clashes may 
occur between two adjacent ground stations initiating simultaneous session 
requests. However, this will be an unlikely and inconsequential condition 
because of the short message length and unique identification codes. Receipt 
of a valid code by the Space Station will initiate a full duplex handshake 
condition. The predetermined protocol for ground station initiation can 
require a specified monitoring period prior to transmissions. This is 
analogous to the interrecord gap on a base band data bus. The selection of 
this and other wait periods must be analyzed to fully utilize the system 
bandwidth. This protocol determination is beyond the analysis reported in the 
document. 

3.8.4 DIRECT BROADCAST IMPLEMENTATION ALTERNATIVE 

Several alternatives were indicated in the previous paragraphs. They are 
summarized below: 

o Optimization of number of SS antenna vs. frequency bands 
and directional ity 

o Selection of ground station directionality 

o Sizing of session initiation messages and content 

o Relationship of error correction coding versus 
retransmission to scheduling flexibility 

o Table look up positioning vs. beacon homing 

o Ground station pointing and protocol determination 
studies 

3.9 ON-BOARD DATA ANALYSIS 

A function of the Space Station data system that will significantly impact its 
complexity and operational philosophy is on-board data analysis. This has not 
been an appreciable function on previous spacecraft although it has its analog 
In the quick look data system of some ground systems. The justification for 
on-bpard data analysis is to permit real time adaptations of experiments, 
sensors, data acquisition elements, and operational processing to maximize the 
information acquisition of ephemeral phenomena. A specific instance that 
illustrates the benefit of on-board analysis would be the acquisition of 
multispectral images involving both active and passive sensors. For this 
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e^tample, there will be some limited opportunity for acquisition over the 
designated target area as dictated by the orbital dynamics of the spacecraft. 
Some sensors may be nadir viewing while others may be the forward or side 
viewing. Some, such as the visible band sensors, would require relatively 
cloud free conditions and daylight illumination. The passive microwave 
sensors could not operate simultaneously with the active microwave sensors. 
The planning and scheduling of this data acquisition requirement is dependent 
upon the atmospheric conditions and the segments of the total task that have 
been already accomplished. On-board quick look assessment will aid the 

decision to abort or aiter data acquisition efforts that are not producing 
data products of acceptable quality. 

3.9.1 QUICK LOOK ANALYSIS SYSTEM CONCEPT 

The system concept for implementing quick look on-board analysis is 

illustrated in Figure 3-7. It should be noted that the system is not si.^ed to 
acconnmodate all acquired data. Only a sampling of the data would be 

duplicated and subjected to quality analysis. This methodology has its 
analogy in high volume raw material industrial processes where quality control 

samples are subjected to detailed analysis as an aid to controlling the 

process. The significant elements in the quick look system are the analysis, 

human interface and the collateral data components. These components interact 
to achieve a system performance characterized by the following attributes: 

0 Flexible 

o Easy to use 

o High performance 

Flexibility Is essential because the main purpose of this quick look feature 
Is to provide experimental ability to alter processing algorithms for 
optimized information capture of the resulting data products. To determine 
the results of the altered process, the quick look system must be capable of 
performing it, albeit on a limited data volume. 

Easy to use is consistent with the theme for the overall Space Station data 
system. The on-board crew and users wl H not be efficiently utilized if their 
training must be overly concerned with how to manipulate their tools. 


3-29 




3-30 


Figure 3~7. On-Board Analysis System 



The value of the human in the Space Station will be to recognize and Interpret 
acquired data. The expected tours of duty are sufficiently short that only a 
shdrt training period can be tolerated before fuii performance is achieved. 
When a system of considerable sophistication and complexity Is considered^ the 
human interface must be easy to use. 

High performance, within the constraints of limited data volume, is a 
necessary attribute because of the near real time processing requirement. The 
value of the function is in its ability to provide the user with useful 
Information with which he may better optimize the acquisition and information 
extraction process. Thus the information is needed in a timely manner. 

To achieve these qualities, automation of functions that have traditionally 
beCn performed by humans will be required. These functions will require 
accessing diverse collateral data bases, making judgmental decisions and 
Inferencing results without having predetermined procedures identified. These 
disciplines are within the technology of artificial intelligence (Al). Also 
within Al are techniques for making systems easy to use. Generally these 
approaches tend toward natural emulation of human functions. Natural language 
is predominant for these functions. 

3 . 9.2 ARTIFICIAL INTELLIGENCE PARTITIONING 

Having introduced notions that have counterparts in Al research, additional 
applications will be explored. The needed access to collateral data can draw 
upon techniques of knowledge organization. This is discussed under the 
heading of self-organizing data bases. There have been several experimental 
applications Involving Al that have potential application to on-board data 
analysis. These systems have been applied to automated work planning which 
would aid in sensor selection and scheduling and to data fusion and perception 
which applies to automating the analysis function directly. Other A! systems 
In various application domains offer interface features that are applicable. 
These systems are presently exhibiting natural language processing 
capabilities or have been applied to explanation and training. Several 
systems that have been implemented to reason and automatically perform work 
planning are listed in Table 3-3* There have been several systems developed 
for so called data fusion or multi spectral analysis and feature vector 
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Table 3“3* Al Systems for Work Planning 


ORIGINAL f^AQE IS 
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extraction. Some are directed toward extraction of spatial information 
to identify objects. Some have particular capabilities to lea^n what is 
significant in scenes to extract classification information. Others 
automatically apply classification techniques to a variety of data inputs. 
The systems have been directed towards easy use and manipulation of the data. 
These systems are listed in Table 3~^. 


Table 3*^. Al Systems for Perception and Data Fusion 


Perception 

Learning 

Interpret ing 

Interact 1 ve 
Aids 

ACORN 

AQ1 1 

BETA 

AlPS 

AQVAL 

CLS 

Dipmeter Advisor 

HAWKEYE 

INTERPRET 

CRAPS 

MSIS 


POLY 

103 

MSYS 


VISIONS 

INDUCE 

SLAP 

SU/X (HASP) 
TATR 



3.10 GROUND SUPPORT 

Ground support for tne Space Station will take on a much broader role than 
with previous spacecraft. Due to the indefinite lifetime with regular 
resupply, the ground support facility will be a regularly functioning node in 
the total system, managing, storing and processing products ranging from raw 
material to logistic supplies to data. The development of these details is a 
normal function of system definition which is not addressed in this report. 
These functions are identified in Appendix A. 

Of major concern is the ability to streamline and accommodate the requirements 
analysis, system engineering, and software development activities as 
coritinuing elements in the entire operating process of the Space Station 
system. These activities have been discrete planning and engineering 
functions in the life of previous satellite programs. The concept considered 
here is to relegate these functions to operating elements in a 
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continuous process ''pipel inet*' By planning these functions as an integral 
part of the total system^ knowledge acquired during the early design phases 
will assure ready transfer to subsequently evolving systems. This concept is 
depicted In Figure 3*^8 , 

3.10.1 SPACE STATION SYSTEM ELEMENT LIFE CYCLE 

In the most general sense^ the Space Station will comprise a collectiii^n of 
system elements. Each element may be represented as a black box with 
interfaces and the capability to exert influences on those interfaces. In 
reality^ the boxes may be hardware, software, or combinations. The 
significance is that each of these elements has a definite life cycle through 
which certain metamorphosis may take plac^li^ Each element has at least a 
seminal genesis in the perceived need to do something. These perceived needs 
are usually called user requi remen tr^. They are also usually vague, incomplete 
and, when considered in total, «ieinfnwt‘ng. The process of resolving 
conflicts, completing the definition, and maintaining traceability is called 
requirements analysis. it is a labor intensive process utilizing highly 
skilled personnel. The resulting requirements comprise a system specification 
which Is subjected to extensive engineering analysis to produce system design, 
functional partitioning, hardware and software partitions, and detailed 
specifications. Again, this |s labor Intensive utilizing skilled resources. 
By systematizing the process with compatible centralized data management, each 
of the system elements can be consistently analyzed and the benefits of modern 
analysis tools can be made available to everyone working on the system. At 
any given instant, system elements will exist In various stages of the 
process. New or altered requirements will be generated during the engineering 
process and later during on-board operations. Ultimately, the resulting 
optimized partitions will find their way into implementable hardware and 
software. Along the way, test, verification and operating procedures will be 
developed. The result will be a factory for supporting the present flight 
portion of the Space Station system. 

3.101.2 CRITICAL ELEMENTS 

The support system outlined in Figure 3-8 has some critical elements that are 
not restricted to a particular segment of the process. They are primarily 
concerned with the management of large heterogeneous dnta bases and the 
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Figure 3-8. Integrated Ground Support System 



friendly interfece with the operetors. Both of the&e concepts ere discussed 
elsewhere. 

3.10.3 REQUIREMENTS MANAGEMENT SUPPORT 

The key feature of the requirements management elements is the recognition 
that the initial requirements will be vague, partially defined, and 
conflicting. The system should be capable of accepting such requirements and 
transforming them into complete requirements. This transformation will 
require a series of separate but cooperating subsystem specialists. Such 
concepts have been successfully employed in expert systems such as ETHER, 
HEARSAY III, PS I, and SAFE. ETHER and HEARSAY III are both general purpose 
and might be directly applicable. PSI and SAFE are both systems in the domain 
of automatic programming, but exhibit concepts that are applicable in the 

requirements management domain. These systems are further identified in Table 
3-5. A rudimentary concept of the requirements management system is sketched 
in Figure 3 - 9 . Natural language processing, interaction with the operators, 
and the many knowledge-bases are implicU. Only major components are 

identified. 

3.10.3.1 Requirement Recognition 

The first component of a requirement management system Is the recognition of a 
requirement. The input format should be easy and natural. Many of the human 
friendly natural language interfaces addressed elsewhere are appropriate. 
Beyond that, there is the need to accept anaphoric reference and the vast 
amount of information implied by context. The conceived systems are rich in 
contextual information because the environment is the Space Station and 
references to the particular experiment or subsystem involved. Systems such 
as COOP, GUS, JETS, NUDGE, and QUIST provide good prototypes and models for 
inferring meaning. These systems are further identified in Table 3 - 6 . Many 

of these systems were developed for the domain of data retrieval.- 

Nevertheless, they have features applicable to recognizing requirements. COOP 
is capable of detecting violations between a user's presumption and a present 
state and then formulating correct, indirect, and more informative responses. 
This is a desirable feature to rapidly resolve ambiguities Interactively, over 
and above the friendly interface components. G'JS uses knowledge frames, much 
like scripts, to infer missing information based on what is expected for usual 
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Table 3 - 5 . Systems Utilizing independent but Cooperating Subsystem Specialists 
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Figure 3-9- Sketch of Requirement Management Systei 




Table 3-6. Systems that are Models for Requirement Recogniti 
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properties of known concepts and what typically happens in familiar 
sitpations. JETS specifically addresses difficulties of anaphoric references, 
ellipses, and other context dependent deletions. NUDGE is a front end for 
conventional scheduling programs that accepts and understands incomplete and 
inconsistent requests. It also uses frame-based semantics to resolve 
anaphoric requests. QUIST is directed toward date base accesses and improves 
the execution by using semantic constraint information available from the data 
base schema. 

3*10.3.2 Requ i rement Understand i nq 

The marked deviation of the conceived system from more conventional 
requirements management systems is that this system understands the 
requirements rather than merely manipulating and keeping track of them* Every 
requirement will be referenced and translated into an internal representation. 
This is conceptual dependency. This idea was advocated by R.C. Schank (Schank 
5 ). Meaning is encoded by decomposition into a small set of primitive actors 
with actions and objects. This concept is used in several of the knowledge 
representation systems and languages such as FRL, KLONE, KRL, KRS, NETL, RLL, 
SYSP and UNITS. These are discussed under the data management topics. 
Knowledge in the understanding portion of the system would aid the requirement 
recognition process. The recognition portion would be activated for 
clarification when the understanding portion failed. The objective of the 
understanding portion is to identify unambiguous requirements. They may still 
be incomplete and conflicting. A system that offers an applicable model for 
this portion is SAM. SAM (Script Applier Mechanism) is a program developed by 
Roger Schank, Robert Abelson, and their students at Yale University to 
demonstrate the use of scripts in understanding stories. Conceptual 
dependency representations are manipulated using scripts to establish the 
context of events. Scripts are frame-like data structures that provide 
stereotyped sequences of events that may be considered usual behavior in a 
particular context. SAM comprises three parts: PARSER that accepts English 
Input and transforms It to conceptual dependency representation, MEMTOK that 
makes inferences, end APPLY that applies the script. For additional 
reference, see (Barr l) and (Schank k), 



3 JO. 3* 3 Requirements Planning I 

The next portion of the system has the goal of developing complete, detailed 
requirements. There are combinations of approaches to performing these tasks 
th»t have precedence in several systems. These are planning systems, 
particularly in the robotic domain. Examples are INTERPLAN^ HICROPLANNER, 
NOAH, PLANNER, and WARPLAN. Other systems hypothesize a solution and then 
prove it. Given an overall requirement, based upon knowledge In the 
knowledge-base or inferred knowledge, additional subgoals will be generated or 
discovered by search. In some cases the subgoals will not complete the goal 
path but will advance the present state closer to the goal leaving the 
complete solution to other attempts. Some systems using theorem proving 
approaches are GPS, IMPLY, and QA. The generation of a complete chain of 
subgoals is analogous to the generation of complete requirements. 
Consequently, the Indicated systems offer models for the planning portion of 
the system. A further identification of planning, problem-solving, and 
theorem proving systems is provided on Table 3-7. 

3.10.3*^ Conflict Resolution 

Having complete unambiguous requirements is not the end of requirements 
management. These will originate from many sources and have different times 
during which they will remain valid. Individually, there will be conflicts 
which the next portion of the system will attempt to resolve. In effect, 
there will be many sets of requirements for the Space Station according to an 
associated time line. The result of the good and complete requirements will 
be a large data base. The only concern In the discussion is the need for 
tools or a system to formulate searches within that data base. The conflict 
resolution portions will involve search mechanisms for needed data. It will 
also involve an Interface to more conventional, yet still not commonplace, 
requirement management tools such as SREM (TRW 2, 6E ^). The conflict 
resolution portion of the system will itself be an expert system. Production 
systems constructed using languages and system structures such as EMYCIN, 
HOLGEN, OPS and OWL are appropriate for this portion of the system. For 
additional information on these systems, see Table 3-8. 
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Table 3“7- Planning, Problem Solving, and Theoron Proving Systems 
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Table 3~8 . Some Basis Systems for the Conflict Resolution Subsystem 
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3<10.3*5 Regu i rement Generat I on 

The final step in requirement production is the generation of the requirements 
in the consistent compatible format with the other portions of the overall 
system. Some of the production system features applicable to conflict 
resolution may also be applicable to this portion of the system. Implicit in 
the total process is a management of the many sets of requirements, each with 
a different time value. This requirement generation portion has the objective 
of pr yiding the requirements in the proper format. Throughout the process, 
human interaction and changes are anticipated. Traceability and ease of 
verification are overall goals. 

3.10.4 ENGINEERING AIDS 

Once requirements are defined, the system engineering process begins. The 
concept illustrated in Figure 3-8 has the effect of integrating the many data 
products and tools Into a consistent format for easy repetitive flow through 
the system with a minimum of human translation. Many of the tools such as the 
various structured analysis programs, loading and scheduling programs, and 
simulators are large and cumbersome. Aids to the use of these tools would be 
incorporated. An example of a successful application of intelligent aids Is 
SACON. SACON is an expert system in the engineering domain developed by James 
S. Bennett and Robert S. Englemore at the Heuristic Programming Project, 
Stanford University. It was built using EMYCiN as its framework. SACON 
provides automatic consultation to engineers in the use of a structural 
analysis program, MARC. MARC uses f in i te^element analysis techniques to 
simulate the mechanical behavior of objects. The user of MARC knows what is 
desired but does not know how to set up the program. A year of experience 
is' typical of the time required to learn how to use all of KARC's options 
proficiently. SACON recommends an analysis strategy to guide the MARC user in 
the choice of specific input data, numerical methods, and material properties. 
The system contains some 160 rules and 50 attributes^ half of which are 
concluded by the rules. SACON is described by Bennett and Englemore in the 6 
IJCAI , pages 47 to 49, "SACON": A knowledge-based consultant for structural 
analysis." 

The list of engineering aids can be quite extensive and is not developed in 
this report. However, mathematical tools, physical knowledge assistance, and 
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simulators are all candidates* A general purpose simulation system such $s 
Data System Dynamic Slmulatlpn (DSDS) (Geer 1, Golden 1)^ will prdvlde the 
next step In the system design process. System functidhs can be simulated 
without forcing the hardware/softijVare nai'tltlon. Mission timelines can be 
developed and when necessary » requirements can be altered for an additional 
pass through the system. 

The output of this portion of the overall system will be the Space Station 
system design, mission plan, procedures, and all the accompanying 
documentation. Some data formats will be directly compatible With computer 
aided design, manufacture, and test. For software, the specifications will be 
sufficient for direct Implementation by the software management system. 

3.10.5 SOFTWARE MANAGEMENT 

The software management system has the management of all the specified 
software elements of the Space Station system as Its objective. There will be 
many sets of software as the system evolves. An exact duplicate simulation, 
or model of the current system, along with the necessary simulation of the 
hardware environment will be included In this portion of the ground support. 
Capability to re-enact historical configurations will be required for some 
post event analyses. Many versions of future configurations will be required 
to assure that problems will not be introduced when computer software Is 
changed while the Space Station is operational. As a goal toward the 
consistent generation of reliable computer software, automatic programming 
systems have future potential. 

Automatic programming has taken on a variety of definitions as attempts have 
been made to relieve the programmer of soffie of the burden In order to Improve 
productivity. The first FORTRAN compiler was regarded as "automatic 
programming" In I95A. Today, when most programming is done In high level 
languages, automatic programming implies an even more advanced programming 
environment. Since programmers are usually considered to exhibit Intelligent 
features In the performance of their work, it Is rational that attempts to 
automate more of this work involve Al research. An entire chapter In Volume 2 
of the Handbook of Artificial Intelligence Is devoted to automatic programming 
(Barr I). 


Eirlf automatic prografnmlng systems were pradoralnently based on theorem 
proving. Others concentrated on program transformation which Is not too 
different from compiler optimizers in the traditional sdnse. The introduction 
of knowledge engineering* especially knowledge about programming and the 
domain* has greatly Improved the potential for automatic programming. 

Another conceptual approach is automatic data structure selection. It allows 
the selection of efficient, ipw-level data structure Implementation without 
incurring the penalty of the abstract data types that are default implemented 
by most compilers as a compromise between efficient implementation and likely 
users. Other approaches are traditional problem-solving using heuristics and 
Induction methods for inference, program from examples, input/output pairs, or 
incomplete specifications used in conjunction with the domain knowledge-base. 
Some automatic programming systems that implement concepts with potential 
application to the software management system are indicated in the following 
paragraphs. 

3.10.5.1 PS I and CHI 

PSi and CHI are automatic programming systems that are presently considered to 
have achieved the greatest degree of success and generality. PSI is a 
knowledge-based system that integrates several concepts. It was developed by 
Cordell Green and his colleagues at Stanford University. A program Is 
specified by means of an interactive, mixed initiative dialogue, which ma^ 
include partial specifications by examples of input/output pairs or by traces. 
A PARSER/ INTERPRETER, EXPLAINER, DIALOGUE MODERATOR, and EXAMPLE/TRACE 
INFERENCE cooperate with the user to construct a program net that describes 
the desired program. Then the PROGRAM-MODEL BUILDER module converts the net 
into a complete, consistent description of the program, called the program 
model. Next, the CODING and EFFICIENCY modules, through repeated 
transformations, convert the program model into an efficient implementation in 
the target language. (Ginsparg, Steinberg, Phillips, McCune, Barstow Green 
1). This approach of integrating cooperating specialists is appealing for the 
Space Station environment because many of the knowledge domains can be 
predetermined and segmented along lines of space system discipline, 
applications, and Space Station subsystems. 



CHI (Green 2j KedzieJ'fkl) |s of (ntcrcst to the Space Station ioftware 
management systenr because It is an extension of PS I with an emphasis on the 
environment. It uses the very high level, wide spectrum language *V- for 
specifying both programs and programming knowledge. The CHI project would 
also serve as a convenient paradigm for the extension and application of a 
complex system like PSI to a different environment (i.e. Space Station). 

3.10.5.2 PECOS 

PECOS (Barstow 1,2,3) Is of special interest because it is the automatic 
coding expert in PSI at Stanford University. PECOS is a dynamic 
transformation system that has a knowledge’*base of transformation rules. it 
begins with a complete specif icatlon and, through repeated selection and 
application of the rules, a gradual refinement process results in an 
implementation in a target language. PECOS works on symbolic programming, 
originally LISP. It is of special interest because it operates in a stand- 
alone mode and Schlumberger Ltd. has ported it for applications of generating 
and maintaining FORTRAN programs. 

3.10.5.3 SAFE 

The fourth system of special Interest to Space Station automatic programming 
is SAFE (Balzer 1,2,3,^) because it is an extensive system that treats the 
problem as two subproblems. The first part is the development of detailed 
specifications in a high level program specification languages, AP2. The 
second part Is the optimization of that program specification. The 
unaddressed part is code generation which can be similar to the final stage of 
conventional compilers. 

The SAFE system views automatic programming as a production of a program from 
a description of the desired behavior of that program. The system accepts a 
program specification comprising preparsed English, including terms from the 
problem domain. They can be incomplete and ambiguous. It Is not necessary to 
describe the algorithm of how a transformation is to be accomplished, only 
what is to be accomplished. The system has internal mechanisms to account for 
efficiency and other concerns for data representation protocol, resource 
utilization, et cetera. 
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3,10.5.^ Other Automat ic Programming Systems 

Other systems with specfific Interest for this application are PHENARETE, 
Prograrrmer's Apprentice, AURA, ACE, and HACKER. Each has some concepts €?f 
particular merit. PHENARETE (Wprtz) Is a program debugging aid. It aaSr^ts 
Incompletely defined EISP programs, evaluates them, and using a library of 
rules and specialist modules^ fines them. It uses a specialist module for 
each function and It also provides explanations of what it did and why. The 
system is also applicable to PASCAL and ALPHARO. 

Programmer's Apprentice (Rich) Is an Interactive system for helping 
programmers with the task of programming. The system may be conceived as 
midway bptween an aid to Improved programming methodology and an automatic 
programming system. A programmer and the apprentice work together through all 
phases of the development and maintenance of a program. The programmer does 
the diffleuk parts of design and Implementation, while the apprentice acts as 
Junior partner and critic, keeping track of details, and assisting In 
dorr^tOKation, debugging, and modifications. The emphasis Is on the ability 
of rhe programmer's apprentice to understand the program. 

AURA is an Automated Reasoning Assistant and automatic programming aid 
deveToped at Argonne National Laboratory and Northern Illinois University. 

ACE, Implication Coding Expert, Is a pro^iram initiated In 1982 by Pierro P. 
Bonissone and John W. Lewis of General Electric Corporate Research and 
Development Laboratory at Schenectady, NY. This program has an objective to 
develop an implementable conceptual model which will enable the average 
programmer to approach expert programmer performance in particular 
applications domains. The system accepts natural language requirements which 
are parsed and built Into a partial conceptual model. interactively, missing 
components are requested and checked for completeness. The resulting 
requirements specifications are then matched with implementation frames from a 
knowledge-base. The system constructs plans for the software program from the 
knowledge-base and Interactive "customs" which do not yet have a counterpart 
in the knowledge-base. The resulting plans are subjected to additional 
analysis using other rules to diagnose errors and suggest optimization. 
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HACKER is a system built by G. J. Sussman in an attempt at automatic 
programming* it is based upon the heuristic compiler of H. A. Simon which 

regards the task of writing a computer program as a problem-solving process. 
HACKER generates *'buggy'* code without detailed planning* detects and 
g?!neralizes the bugs* and then defines appropriate operators to resolve them. 
Some features incorporated in HACKER are: learning through practice how to 

write and debug programs; modular* pattern- invoked expert procedures* i.e. 
chunks of procedural knowledge; and hypothetical world models for subgoal 
analysis. 


SeCTiON ^ 

TECHNOLOGY NEEDS 

The distribution of data system functions and the corresponding control In 

varying degrees of autonoinous operations will require development and ^ 

evaluation of key concepts prior to commitment In the system architecture. 

The desirability of those concepts will be subjected to continuing analysis as 
the Space Station program evolves. The effort and risk of using them will be 
a factor In assessing that desirability. This section provides an Initial 
precis of the presently perceived technology needs should the subsequent 
analysis of the concepts Indicate that the concept Is desirable. 

Based on the early analysis, the driving factor for technology needs appears 
to be automation, In particular, the automation of data management functions. 

This is not too surprising since automation of other functions has been i 

pursued for some time. It Is only recently that serious attempts were made to ^ 

employ automation techniques, because the data management problem was f 

perceived as unmanageable using traditional labor Intensive techniques* 

Those candidate technologies and their characteristics are listed In Table 
and are briefly described In the remainder of this section. 

k.l AUTOMATED WORK PL ANN 1 NG AND SCHEDUL I NG 

In present day usage, ••command management'^ Is restricted to the transformation 
of general requests for spacecraft operations into minutely detailed 
operational plans. Within the context of today's spacecraft, these plans 
contain an enormous amount of Information Including complete and, at times, 
minutely detailed spacecraft position attitude descriptions, and 
communications contact description. Spacecraft configuration Information 
Including all the specific spacecraft commands with specific cofnmand execution 
conditions, Instructions to ground system personnel, time lines, histories, 
various verification products (e.g., computer images), and measures of 
spacecraft performance, health, safety and efficiency Is also contained In the 
operational plans. This planning Is accomplished by using a formal Command 
Management System {CMS) which provides the Mission Operational Control Center 
(MOCC) with sequences of spacecraft commands. These spacecraft command 

1,-1 5 
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Table ^-1. Candidate Technology Developments Required 


mammmm 

Anticipated Need or Benefit 

Automated Work Planning 
and Scheduling 

Needed to perform command 
management. 

Requirement Management System 

Needed to reduce manpower and 
assure completeness of changing 
requirements and pseudo-real 
time implementation. 

Engineering Aids 

Needed to reduce time to verify 
and Implement changing 
configurations as missions and 
requirements change. 

Software Management System 

Needed to reduce risk and cost 
of implementing software 
changes in operational system. 

System of Self-Organizing 
Data Base 

Needed to support changing mix 
of operational and applications 
data and requirements. 

Human to Data System 
Intelligent Interface 

Expected complexity of data 
system requires a simplified 
Interface to free humans for 
their primary roles. 

Automatic Configuring 
Computer Bus and Operating 
System 

Inherently required in 
architecture identified. 
Facilitates upgrades and 
f lexibi 1 i ty wi thout impacting 
software. 

Space Qualified Large 
Screen Display 

Multiple sensor data will have 
utility for several crew members. 
Desirable not to restrict their 
physical movement. 

Qualification System 
for Data System Components 

Multiple users will benefit by 
being able to bring along 
modules. 

Safety and costs are prime 
drivers. 

Di rect Broadcast 

High bandwidth communications. 
Data of parochial interest. 


k-2 
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sequences are derived from genera) requests for specific operations made by 
experimenters, mission operations personnel or mission support personnel. The 
CMS performs all of the functions necessary to transform these general 
requests into detailed operational plans including all of the general and 
special output products. This assures safe, efficient, and coordinated 
spacecraft operations. 

In the present system with a large number of free flyers, each directed toward 
single or relatively few missions, there are a large number of specialized 
CMSs. The size, nature, complexity, and operational characteristics of each 
CHS are determined by a large number of highly variable spacecraft, mission, 
and operational characteristics; consequently, each CMS is highly tailored to 
the individual mission. 

Within the context of free flyer systems, OR! has classified CMSs and the 
categories of functions performed. These are reported in (Rogers 1). The 
functions are listed in Table 4-2. Within this same report, four types of 
CMSs were identified with type 4 having the greatest complexity. The 
classification system is repeated as Table 4-3. 


Table 4-2. Major Categories of Functions Performed by CMS 


1 ^ * 

User Interactive Communications Functions 
(User Oriented Language) 

1 

Edit Functions 

1 

Maneuver Related Functions 

4. 

Command Sequence Generation 

5. 

Constraints Consideration 

1 

Command Memory Management 

7. 

Simulation and Training Functions 


For the Space Station, the challenge becomes one of implementing a CMS with 
ail the attributes of type 4 but in a far greater degree. There will be a 
multiplicity of users and missions not necessarily related in any commonality 
other than the ability to share the same orbital position in space. The 
sustained operations have a related indefinite lifetime. There will be many 
more constraints. The systems will be more autonomous and will have greater 
functionality. There will be a near real time requirement. The culminating 



ORIGINAL PAGE IS 
OF POOR QUALITY 


Table ^-3. Attributes which Determine the Type of CMS. 


Type 1 

0 A single on-board memory 

0 Nearly all commands result from explicit user requests 

o Only five basic functions: a) input editing, 

b) merging, c]< assembling, d) fabrication, and 
e) output interfacing 

0 Prescribed contact stations 

Type 2 

o Modeling of command sequencing logic required 

0 Some modeling required to determine commands 

o Dynamic management of on-board memory regions provided 

Type 3 

0 Coordination of several experiments 

o Spacecraft controlled by separate on-board computer 

o Experiments contain microcomputers or command memories 

o Coordinate functions for many experiments 

o Limited 3-axis pointing by command 

o Some constraints checking 

Type 4 

o High-fidelity modeling of spacecraft subsystems 

o Sustained spacecraft operations 

o Extensive constraints modeling 

o Continuous 3-axis pointing by command 

o Interfacing and coordi nat i ng wi th several users 


difficulty Is the desire to provide on-board autonomy, which means a 
significant portion of the CMS must be on-board the Space Station. 

A.t.1 ISSUES OF AUTOMATED COMMAND MANAGEMENT 

Some of the issues associated with automating command management for near real 
time on-board command acceptance, generation, and execution are listed In 
Table 
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Table k-h. Issues of Command Hanagement 


o 

What partitioning and priority of requests for 
commands should be implemented? 

o 

How much autonomy can be vested in individual 
subsystems to off-load the burden on the CMS? 

o 

To what extent can the on-board CMS be dependent 
upon ground support? 


Is It really impossible to implement CHS in the 
traditional algorithmic approach? 


^.1,1,1 Partitioning and Priority 

Some of the partitioning and prioritizing categories of command origination 
are: the commander and other humans responsible for the well being of the 
Space Station and its missions^ ground personnel with similar 
responsibilities, automatically operating subsystems on the Space Station or 
in ground segments, on-board mission specialists and crew members, on-board 
principal investigators, official ground-based Space Station personnel, and 
other individual ground investigators. Each of these sources of command 
initiation and constraints must be considered. Within each source, differing 
criticality and timeliness requirements are expected. The concept of direct 
experimenter interaction with the space-borne sensors has been identified but 
merely from the viewpoint of the user and not the implementor of the CHS. A 
scenario whereby artificial intelligence is incorporated in a direct user 
interaction CMS is illustrated in Figure A-l. 

A . 1 . 1 ,2 Hierarchical Distribution 

The off-loading of detailed microcommand generation to individual subsystems 
is in keeping with the hierarchical control concept which is successful for 
complex systems, whether army, government, business, or biological organisms. 
The hierarchical control concept is workable when the system has a high degree 
of capability or "intelligence," which is the condition being approached for 
the autonomous Space Station data system. The command and control structure 
for such systems is invariably a hierarchy wherein goals or tasks selected at 
the highest level are decomposed into sequences of subtasks which are passed 
to the next lower level in the hierarchy. This same procedure is repeated at 
each level until, at the bottom of the hierarchy, a sequence of primitive tasks 
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Figure 4-1. An Application of Al to Advanced Systems 




which cen be enecuted with single actions is generated. Sensor/ feedback 
enters the hierarchy at many different levels to alter the task decomposition 
to accomplish the highest level goal in spite of uncertainties or unexpected 
conditions In the environment. 

For a further description of hierarchical control see (A)bus I) which 
describes the National Bureau of Standards applications to factory automation. 
A theory of hierarchical control Is presented in this report incorporating 
three parallel interconnected hierarchies. The first Is a behavior-generating 
hierarchy which decomposes tasks into subtasks in the context of sensory 
Information. The second is a sensory-processing hierarchy which extracts the 
information needed for goal seeking behavior. The third Is a v.orld-model 
hierarchy which generates expectations and predictions for the sensory- 
processing modules at each level. A robot control and vision system is 
described that implements the triple hierarchy model in a microcomputer 
network. A possible application of the theory to an automatic factory control 
system Is outlined in (Albus I). 

Ground Dependency for CMS 

The extent to which the on-board CMS can be dependent upon ground support is 
an additional aspect of that same question with regard to autonomy for the 
entire Space Station. Reliability, communication channel requirements, 
mission criticalities, and the performance of the various components required 
for implementation must be considered interactively. The resolution of this 
issue will necessarily involve the Space Station system as a whole. 

Algorithmic Implementation of CMS 

Algorithmic implementation of automatic command management is probably the 
current most controversial issue. It has been implemented in rather 
restrictive domains. The generation and verification of the necessary 
algorithms and supporting software is extremely expensive. It is doubtful 
that such an approach is practical in the context of the Space Station. 
Interesting alternatives that have some history of success within NASA at JPL 
involve A I approaches 

In most realistic environments, it will be impossible to completely build a 
detailed plan and execute it in an unmodified form to obtain the desired 


result. A further complication arises when the plan must meet real time 
constralnts-^-that Is, definite short'-term requirements for actions where 
failure to meet the timing requirements carries significant undesirable 
consequences. Because of this> It Is Important that complex autonomous 
systems have plan formation capabilities well In excess of current state-of- 
the-art. 

In 1980 , Al was advocated as an essential technology for Implementing 
autonomous command management (Long I). At that time there was a growing 
awareness among Al researchers that the time had come to produce limited 
capability In a useful working system. The following is from Long's report. 

"Theoretical research In Al problem-solving and planning techniques 
will be an active area for several decades to come. If NASA is to 
become effective In directing this research toward its own goals, 
then early experience is necessary with elementary state-of-the-art 
techniques — although substantial advantages can even be obtained by 
relatively unsophisticated, near-term Al planning and monitoring 
techniques." 

That the assessment of the maturing nature of Al was correct Is further 
evidenced by the spurt of interest in the technical literature. (Gevarter 1, 
Hayes 1, Duda 1, IJCAI I, Barr 1) and even the popular literature (Business I, 
Webster I, Yasakil I, and Business 2). Industry interest is also apparent as 
evidenced by the major corporate programs involving Al. The rapid maturity of 
Al Is probably most succinctly stated by Peter Hart of Fairchild Camera and 
Instruments Corporation when he said "It has taken At twenty-five years to 
become an overnight success." 

The exploration of the issue of applying Al techniques versus the traditional 
algorithmic approach for automatic command management is a major effort. It 
is compounded by the relative newness of the A I field. 

if. 1.2 APPROACH TO AUTOMATED COMMAND MANAGEMENT 

Further analyses of this technology will be based upon some of the traditional 
approaches as documented in recent study reports (Rogers 2, Rogers 3). 
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k.l REQUIREHENT HANAGEMENT SYSTEM 

The system engineering process of assimilating requi rementS| synthesizing 
solutions, accommodating constraints, resolving conflicts and traasforming the 
entire concept into a smoothly functioning system with well conceived plans, 
schedules and supporting paraphernalia has developed with the space program. 
With the advent of the Space Shuttle, concerns were expressed that somehow the 
lengthy, labor intensive process had to be streamlined to effect timely 
turnaround of diverse missions in a more cost-effective manner. An analogous 
problem must be faced and planned for with the Space Station. All concerns 
for the operational complexity and cost of an indefinite life, manned Space 
Station with changing multiple concurrent missions are embodied in the need 
for an efficient and effective Requirement Management System, Efficient 
implies a system capable of performing the necessary activities with a minimum 
involvement Of humaii resources. Effective means that all items will be 
accommodated and no critical problems will remain unresolved. All this has to 
be accomplished while the Space Station rema i ns operat i ona 1 i 

The development of automation tools and interactive computer assistance 
systems to improve the productivity of the mission planners, the system 
designers, and the software generation is deemed a critical technology for the 
progression of the Space Station to the fully operational state envisioned. 
The development of an integrated concept for identifying and managing the 
requirements is a critical first step. 

I».2.1 ISSUES OF REQUIREMENTS MANAGEMENT 

Some of the issues of requirements management involve the capture of the 
implicit processes that are now performed during the requirements analysis 
phase of system engineering. Most of the implemented systems are applied to 
more restrictive domains than are expected for the Space Station. This study 
serves as a model of the range of involvement. Requirements originate from 
both operational and mission needs. The missions can be widely varied and 
often conflicting. Several parallel studies will provide background for the 
data acquisition process leading up to mission requirements generation. For 
operating support and orbital computational requirements, see (Graf 1, Graf 2, 
CSS 1 and MITRE I). A recent investigation at JSC identified the current 
practices and future approaches for acquiring and utilizing Shuttle Flight 


operations data (Shepperd 1). In this reportf a concept of developing an 

integrated flight operations data management system is identified. The data 
management system would be amenable to eventually Incorporating Al technology. 
Presentlyi there is no singular source of potential mission requirements. 
Earlier studies provide pattial and unofficial sources (des Jardins l»GE l). 

4.2.2 APPROACH TO REQUIREMENTS MANAGEMENT SYSTEM 

The development of an integrated concept for requirements managemenf Is the 
first step In an end-to-end system that will include a significant amount of 
automation In the generation and production of hardware and software 
components. Software in this sense includes documentation, test plans, and 
operating procedures as well as computer programs. Such concepts are 

currently considered and are being implemented by major System integration 
companies in limited scope. They are frequently termed the environment for 

requirements development. These environments have some characterizing 

features: 

o Provision for easy interactive iteration between system 

requirements, development personnel, and mission requirements. 

o Software simulations of system implementation without regard for 

hardware or software partitioning. 

o Traceability of requirements and impact of configuration changes. 

The development of a requirements environment concept will require three major 
activities: 

1. The research of related effort which, at present, Is quite limited. 
Parallel activities In the area of software development environments 
wM I provide some guidance. 

2. The development of the functional catalog of what role this system 
would perform. 

3w A synthesis of a possible implementation. 

4.3 ENGINEERING AIDS 

The development of automation techniques to Improve productivity of system 
engineering for Space Station operations and minimum planning is the second 
step in automating the end-to-end requirement to implementation support 
activity. Systems have been implemented to provide computer-aided design in 
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the mechanical and VLSI engineering fields* It is plausible that such systems 
can be implemented In specific system Engineering fields when requirements ere 
committed to an on-line automated system* The Intention is to provide 
templates and engineering aids for developing lower level specifications, 
simulating system performance^ and generating component performance 
specifications and test data* 

Consideration of incorporating various engineering aids at the time of 
implementation of the requirements system Will be useful* Again, In the field 
of Al, several concepts in data managemeTit are promising* Each of the 
functions of a data system can be considered a node In a frame structured 
representation system* Such a data structure was described by Minsky as 
fol lows: 

“We can think of a frame as a network ©f nodes and relations* The 
“top levels" of a frame are fixed, and represent things that are 
always true about the supposed situations. The lower levels have 
many terminals — “slots" that must be filled by specific instances 
of data* Each terminal can specify conditions its assignments must 
meet." (Minsky 1) 

The use of frames as a technique for classifying information on the basis of 
its properties is described in Chapter 11, “Simple Discrimination Nets" 
(Charniak 1). Such discrimination nets are sometimes called discrimination 
trees or semantic networks* Links are Identified between nodes and can be 
structured with explicit definitional roles, types of inheritance, defaults, 
and data formats. For a Space Station data system, the links could be data 
flows and dependency relationships could be established* Processing times, 
data bus bandwidth * requirements, data dependency, and a multitude of 
performance parameters could be rapidly and consistently determined and 
checked for conflicts* Complex algorithms can be implemented as attached 
procedures that are treated as other data properties* 

The development of such a concept for system engineering assistance has a 
background of several Al systems available (Stefik 1, Frledland 1, Stefik 2, 
Roberts 1, Bell V, Rychener 1). The domain described by Rychener Is 
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particularly appropriate as It Is the symbolic description and manipulation of 
computer $tructures at the PMS (processor-memory-switch) level. The system Is 
intended for computer-aided design activities. 

k.k SOFTWAHE HANAGEMENT SYSTEM 

The realization that software maintenance will of necessity be performed on a 
live operational manned spacecraft is terrifying to everyone that has ever 
been involved with software systems or spacecraft. Yet^ It is a condition 
that must be faced and planned for. The development of the necessary 
technology to implement and install software changes that will work 
immediately as intended Is a significant challenge for Space Station data 
system planners. The implementation of modern programming practices which 
stress readability, data declaration, encapsulation, and generic units will 
help improve productivity of Software generation and maintenance, but it will 
not provide assurance of correctness to the degree required. 

One opinion is that only by using automatic code generation can the required 
consistency and assurance of correctness be obtained. There are projects for 
generating software automatically, but they are just getting started. The most 
popular initial approach seems to be through the interactive use of templates 
and still Involves human activity to a large extent. This is the approach 
employed In the Programmer's Apprentice system being developed at MIT (Rich 
I). This system is conceived as being midway between an aid to improved 
programming methodology and an automatic prograi\^iing system. A programmer and 
the apprentice work together throughout all phases of the development and 
maintenance of a program. The programmer does the difficult parts of design 
and implementation. The apprentice acts as a junior partner and critic, 
keeping track of details and assisting the programmer wherever possible. A 
key feature of the apprentice is its ability to understand the logical 
structure of a program so that it car interact with the programmer in a 
meaningful way. 

Work on automatic programming systems was pioneered by Barstow and Green In 
the late 1970s (Barstow l-A, Green I). The classic program for developing 
automatic programming is PS I which is summarized in (Green 2). Other 
references pertinent to the PSI program are (McCune 1) and (Steinberg 1). The 
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use of natural language processing in autotnatic programming is described in 
(Ginsparg 1). For a general discussion see (Biermann !)• 

Other related activity to improve productivity is directed toward methods of 
measuring the output of automatic programming systems such as PSIt A system 
called LIBRA uses knowledge-based rules and algebraic cost estimates to 
compare potential program implementations. This system measures '’efficiency'* 
of the resulting pregrams (Kant l). Another system* PECOS, uses expert system 
technology to update FORTRAN programs. This system was developed by Barstow 
et Schlumberger. A system called PHENARETE {Mertz I) Improves incompletely 
defined LISP programs. It takes as Input the program without any additional 
information. In order to understand the program, the system meta-evaluates, 
using a library of prigmatic rules describing the construction and correction 
of general program constructs, and a set of specialists describing the syntax 
and semantics of the standard LISP functions. The system can use its 
understanding of the program to detect errors, to debug them and eventually, 
to justify Its proposed modifications, 

The assessment of the feasibility of automatic software generation for the 
Space Station is premature at this time. An attempt will be made to outline 
the initial effort required to investigate this technology further. Should It 
become operationally reliable, it Is likely that some aspects would even be 
deployed on-board, perhaps Initial./ as an aid for mission analysts and 
principal investigators. it is expected that a system of phased 
Implementation will be desired. Initial effort would likely concentrate on 
more traditional software engineering approaches. Such a system or facility 
would be Incorporated into the Space Station ground facility. It would 
contain a dynamic model of the Space Station and provide some degree of 
emulation of software incorporation prior to installation on the live system. 
An integrated system of requirements management, engineering assistance!^, 
interactive software development center, and verification tools seems 
appropriate. 

i».5 SELF organizing DATA BASE SYSTEM 

The anticipated diversity of undefined missions and other sensor and data 
requirements provides an indication that the data management problem will be 
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horrendous. In anticipation of this need, a desirable condition lyould be one 
in which data structure could be added or removed independently of the 
remainder of the data base, 

Approaches for developing this technology are still being explored. The Af 
researchers are leading In the theory development for methods of knowledge 
representation. Development In self-documenting data sets and even the 
acceptance of packetization schemes that include extensive header descriptions 
should aid this technology. Applications of the semantic network structures 
and frames as discussed under Engineering Aids will provide a basis for such a 
data base. Al systems such as those illustrated in Table 4-5 may be used. 
This concept can also benefit from some of the learning systems that can 
enrich the interconnectiveness, i.e. fill some slots, as the data base is 
maintained and accessed. Significant accomplishments in intelligent data 
management and retrieval concepts have been achieved in selected applications. 

Figure 4-2 illustrates LADDER, a system currently being used by the Navy. It 
is an application of artificial intelligence to access data from a large, 
distributed data base over a computer network. A running system provides real 
time access over an ARPANET to a data base distributed over several machines. 
The system accepts a rather wide range of natural language questions about the 
data, plans a sequence of appropriate queries to the data base management 
system to answer the question, determines on which machine(s) to carry out the 
queries, establishes links to those machines over the ARPANET, monitors the 
prosecution of the queries and recovers from certain errors in execution, and 
prepares a relevant answer. 

The LADDER system (Sacerdoti 1) consists of three major functional components, 
as displayed In Figure 4-2, that provide levels of buffering of the user from 
a data base management system (DBMS). It employs the DBMS to retrieve 
specific field values from specific files just as a programmer might, so that 
the user need not be aware of the names of specific files, how they are 
formatted, how they are structured Into files, or even where the files are 
physically located. Thus, the user can think he Is retrieving information 
from a "general information base" rather" than retrieving specific items of 
data from a highly formatted traditional data base. 
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Figure 4-2. Overview of LADDER System 




The first component accepts queries In a restricted subset of natural 
language. This language processing component produces a query or queries to 
the data base as a whole. The queries to the data base refer to specific 
fields but make no mention of how the information in the data base is broken 
down into files. 

The second functional component called IDA (for Intelligent Data Access) 
breaks down the query against the entire data base into a sequence of queries 
against various files. IDA employs a model of the structure of the data base 
to perform this operation, preserving the linkages among the records retrieved 
so that an appropriate answer to the overall query may be returned to the 
user. 


In addition to planning the correct sequence of file queries, IDA must 
actually compose those queries In the language of the DBMS. The current 
system accesses, on a number of different machines, a DBMS called the 
Datacomputer whose input language is called Datalanguage. IDA creates the 
relevant Datalanguage by inserting field and file names into pre-stored 
templates. However, since the data base in question Is distributed over 
several different machines, the Datalanguage that IDA produces does not refer 
to specific files in specific directories on specific machines. It refers 
instead to generic files , files containing a specific kind of record. It is 
the function of the third major component to find the location of the generic 
files and manage the access to them. 

To carry out this function, the third component, called FAM (for File Access 
Manager) relies on a locally stored model showing where files are located 
throughout the distributed data base. When it receives a query expressed in 
generic Datalanguage, it searches its model for the primary location of the 
file (or files) to which it refers. It then establishes connections over the 
ARPANET to the appropriate computers, logs in, opens the files, and transmits 
the Datalanguage query, amended to refer to the specific files that are being 
accessed. If at ary time, the remote computer crashes, the file becomes 
inaccessible, or the network connection falls, FAM can recover and, if e 
backup file is mentioned in FAM* s model of file locations. It can establish a 
connection to a backup site and retransmit the query. 


A system such as LADDER could be developed and tal lotted toward use on the 
Space Station. Some other natural language systems are shown In Table A-6. 
Further investigation into this area would be extremely worthwhile. 

A. 6 HUMAN TO DATA SYSTEM INTELLIGENT INTERFACE 

An Important function of the vlata system is to provide a friendly interface 
with the personnel on the Space Station. The top down approach to developing 
concepts of this interface starts with the identification of the personnel 
functions and their need to interact with the data system. Some assumptions 
as to the makeup of personnel were mad^, recognizing that this discipline is 
being extensively investigated by other working groups. The assumptions 
continue with the sharp distinction between operations and mission activity. 
A minimum of five personnel is assumed with provisions for as many as twelve 
in the early time frame. These assumed categories, according to their needs 
for data system interfaces or work stations, are listed in Table 4-7. 

There was no attempt to address personnel functions such as "medical officer," 
or others that may be required. These functions, could probably be 
accommodated by any of the categories identified. The categories are; 
commander, chief operations officer, mission monitor and support officer, crew 
member, mission operations, principal investigator, and construction. The 
officers, crew members, and mission operations personnel are considered as 
professional Space Station personnel. Principal Investigators and 
construction personnel are considered temporary visitors and would have 
different data system interface requirements. The initial complement would 
include the officers and one or more crew members or either mission operations 
or a principal investigator. 

4.6.1 MAJOR COMPONENTS OF HUMAN INTERFACE 

Several components such as displays and work stations are envisioned for the 
different personnel categories of Table 4-7* Some devices, such as a large 
screen display and electronic mimic board would provide information for more 
than one category of personnel. The relationship of these components in the 
system is illustrated in Figure 4-3. 
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Table ^-6. Some Natural Language Systems 


SySTEK 

•mm 

DM C 

DM language 

Language 

INTERFACE 

SPEECH 

RECOGNITION 

TEXT 

GENERATION 

ADDITIONAL REFERENCES 

ATHC 



X ‘ 


Kobayashi 1 

BABEL 




X 

Schank 1S2 

CONVERSE 


X 



Kellogg 1 

COOP 


X 



Kaplan 2 

DADH 

X 




Klahr 1 

DEACON 


X 



Thompson 1 

DIAMOND 


X 


i i 

'!* 

DONAU 


X 



Guida 1 

EPISTLE 




X 

** 

ELIZA 


X 



Weizenbautn ls2 

FOOL-UP 


X 



Granger 1 

GSP 


X 



Barr 1| Kaplan 1 

GUS 





Bobrow I 

HAM-RPM 




X 

Wahlstor 1 

HARPY 



X 


Barr If Lowerfe 1 

hearsay 



X 


Barr 1, Erman 1 

hwim 

X 




Barr 1, Wolf 1 

INTELLECT 


X 



*** 

JETS 


X 



Finin 1 

LADDER 


X 



Sicerdot 1 1 

LIFER 


X 



Barr If Hendrix 1f2f3 

MARGIE 




X 

Barr If Schank 1f2f 

MIND 


X 



Kay 1 

PAM 




X 

Barr If Wilensky 1 

PARRY 




X 

Colby 1 

PHLIQA1 


X 



Landsberger 1 

PLANES 


X 



Waltz 1 

PROTOSYNTHEX 


X 



Simmons 1 

QUIST 

X 




King 1 

REL 


X 



Rubinoff 1, Thompson 2 

RENDEZVOUS 

. 

X 



Codd 1 

RITA 


X 



GWU 1 

ROBOT 


X 



Harris 1f2,3 

SAM 




X 

Barr 1 , Schank 3SA 

SDM 

X 




Hammer 1 

SHRDLU 


X 



Barr If Wi nograd 1 

SIR 


X 



Minsky 1 

SNIFFER 

X 




Fikes 1 

SODA 

X 




* 

SPEECHLIS 



X 


Woods 1 

STUDENT 


X 



Bobrow 2 

TAXIS 

X 




Mylopolous 

TEAM 


X 



* 

TED 


X 



Hendrix A 

TQA 


X 



Damerau 1 


*SRI International Proprietary 
**IBH Proprietary 
***AI Corp Proprietary 
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Table 4-7. Personnel Categories 


DATA SYSTEM REQUIREMENTS ] 

o COMMUNICATIONS 
o INFORMATION ACCESS 
o HIGH LEVEL CONTROL S BACKUP 

o SIMILAR TO COMMANDER 
o MORE DETAILED PLANNING 
o INTERACTIONS AND STATUS 
ASSESSMENT 

o HIGH LEVEL CONTROLS 

o ACCESS TO SUBSET OF 

INFORMATION COMMUNICATIONS 
o INTERACTIVE PLANNING 6 
STATUS ASSESSMENT 

o CONTROL AND ACCESS TO 
SUBSYSTEM 

o TEST & MAINTENANCE AIDS 

o SPECIAL PURPOSE FUNCTIONS 
EG. CHECKOUT, OTV, 
MANUFACTURING 

o SPECIAL PURPOSE FUNCTIONS 

o MODULAR l/F 

o PERSONAL ONLY 
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Ffgure 4-3. Some Displays for Human Interface 




Electronic Mimic Board 

The electronic mimic board will have video raster format output which will be 
displayed to a large screen. It will generate digital images mimicking the 
configuration of the Station and detailing the current status of subsystem and 
critical components. This data will be obtained from the performance 
monitoring subsystem and the shared data base. The purpose of the electronic 
mimic board will be to provide warning Indications in case of a malfunction or 
failure. 

4. 6. 1.2 Large Screen Display 

The large screen will provide a display of raster scan video format data 
visible from (5 meters) and (color TBD). Size will be as large as practical 
in the space environment since some of the techniques for large screen display 
(light valves) may not provide adequate lifetime and others such as the direct 
projection may not provide adequate brightness. An assumed enclosed tube type 
of m inches may be adequate. 

The purpose of the large screen will be to display radar, IR, and visible TV 
camera images and digital images plus to serve as electronic mimic board. The 
screen will be visible by both the commander and chief operations officer. It 
could also serve for docking and checkout mission operations. 

A. 6. 1.3 Crew Member Console 

The crew member console will be at a work station with tools for analysis and 
testing of Space Station subsystems and components. The work stations will be 
distributed throughout the Space Station as required. They will provide a 
miniature display of the electronic mimic board and the detailed insets. They 
will simulate mode switching, reaction, et cetera as an aid to maintenance and 
contingency operations. Also, they will provide automatic mcde interlocks 
during maintenance operations. 

These consoles will provide detailed troubleshooting assistance and 
augmentation of built-in test aids to assist in designating corrective 
actions for the crew members in case of malfunctions or failures. They will 
provide an interface for portable media supplement, such as optical or floppy 
discs, with specialized maintenance or procedural information. 

k-22 


4, 6.1. 4 Mission Operations 

Mission operations will be conducted from a work station for routine scheduled 
activities. Configuration of the work station will be modular and will vary 
according to the operation being supported. The three types of operations to 
be supported are: 

o Materials manufacturing 

o Earth viewing image data acquisition 

o Assembly, checkout, and control of OTV Or teleoperator 

Each of these would require different options. For example, OTV or 
teieoperator would require some control and maneuver devices. All will likely 
have some types of displays. The intent is to standardize the work stations 
and minimize hardwired, special purpv^se Interfaces. 

A. 6. 2 GATEWAY REQUIREMENT DEDUCTION 

Future data systems for elaborate spacecraft such as the Space Station will 
necessarily be extremely sophisticated. These data systems will be so complex 
that it would be a major undertaking for any single individual to fully 
understand its Internal workings. The complexity Is expected to exceed that 
of major earth-located automated factories, power plants and such. Such earth 
installations frequently are only understood by long service employees who 
participated in the system evolution. This will not be the situation on the 
Space Station where a frequent change of personnel can be expected. 

Another trend in the future space data systems Is autonomy. The systems will 
be more capable and much less dependent upon the human operators. Thus, there 
will be a lessened requirement to bring Information to the human on the 
Internal status of the system. The design goal will be to free him to perform 
his primary goal and not to burden him with having to adapt to the needs of 
the system. With more capable data systems, the burden of adapting can be 
shifted to the hardware and software system. This is precisely what Al 
researchers are attempting when they are developing systems with humanlike 
qualities. 


A separate human gateway subsystem, or possibly a separate one for each 
ciltegory of personnel, is suggested. If more than one is employed, there 
would be a high degree of commonality of functions, hardware, and software. 
Each human gateway subsystem would have the basic functions of interpreter. 
It would understand the human need for information and obtain It. It would 
interact and ''carry on a conversation," requesting additional clarification if 
it did not "understand" what was expected. The system may evolve from the 
basic concept with increasing functionality, voice synthesis and recognition 
added and modular iy expanded as the system matures. 

For purpose of discussion, eight functions of the human interface subsystem 
are identified. These eight will be required of each subsystem deployed, 
although the degree of functionality and the method of implementation may vary 
for different personnel and the system nature. The eight functions are: 
Input, Recognition, Understanding, Reasoning, Translation, Explanation, 
Tolerance, and Output. Each will be discussed along with some ramifications 
of different implementation techniques. 

I|. 6.2.1 Input 

The input function can be as pedestrian as a keyboard or as sophisticated as 
an imaging scanner. Should vision capability be desired, it would be another 
form of input. A requirement for voice input is a distinct possibility. 
Trade studies are required to determine the needed degree of sophistication 
for voice input. The acceptance of a small vocabulary of trained, single 
word, carefully selected, voice commands is within current technology. Such a 
restricted input would still have many advantages. The reliable functioning 
of a system accepting untrained joined sentences would require extensive 
computational power. While it may be technically feasible in the time frame 
of interest, additional analysis is required to determine if It Is a 
worthwhile feature. 

A. 6. 2. 2 Recognition 

The next function of the human interface subsystem is recognition. This is 
similar to Interpretation. A natural language input capability is understood. 
Consequently, the recognition function would involve parsing and semantic 


h-2k 



inti^rpretation. Access to a reasonable sized data base Is necessary to 
provide the gratnnatical rules and the necessary semantic information to accept 
natural language Input. For the assumed multiple Input formats, multiple 
processing procedures would be required. Some scanner or digitizer inputs 
would have special needs. 

A. 6 .{2. 3 Understanding 

The next important function of the human Interface subsystem Is the 
understanding of what was input. in the simplest of situations^ this would 
require the differentiation between a command and a data input. Understanding 
requires some kind of generic Internal representation so subsequent actions 
can be determined. In many cases, the understanding function will be a 
direction to a particular routine for the generation of a sequence of machine 
code data. 

A. 6. 2. A Reasoning 

Some degree of reasoning will be required for the gateway to accomplish its 
functions. It will be impractical to explicitly incorporate all the 
information required. The human will be making Inferences on his side of the 
interface. Reasoning appears to be a practical way to match the human 
communication mode while limiting the volume of internal information that must 
be processed. 

A. 6. 2. 5 Translation 

This function fs bidirectional and employs as many formats as required by the 
data system. Commands from the human, once understood by the interface 
subsystem, get translated according to where they are directed. The 
translation function includes the generation of the proper syntax or protocol. 
For information directed to the human, a natural language format or a display 
format is employed. 

A. 6. 2.6 Explanation 

This function includes an interactive dialog. When the reasoning function is 
employed to decide what should be done, an explanation may be provided for 
verification prior to execution. Likewise, when cryptic data is obtained from 
the system, additional explanatory information and displays may be accessed as 
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part of the e;<planat|on functions this coi»N be Implemented with mimic boards 
and illustrative mater ial such as might be available from Video disc storage. 
Some of the maintenance aids might employ extensive explanation functions of 
the human Interface subsystem. 

I*»6.2.7 Tolerance 

The tolerance function is the built>ln provision to avoid having to reject 
inputs for syntax errors and spelling variations. It may employ the reasoning 
and explanation function to make assumptions and carry on a dialog to obtain 
needed additional Input information. 

4. 6. 2. 8 Output 

This Is the function that drives the output devicesi They may be displays or 
voice synthesis or more conventional hard copy devices. Whatever their 
form&t^ the output function will accommodate it with the suitable translation 
function. 

I>.6.3 SUHHARV OF HUMAN GATEWAY 

The envisioned human gateway will exhibit five attributes: 
o Understanding 
o Forgiving 
o Easy to Use 
o Multiple Senses 
o Knowledgeable About the System 

A system that exhibits more than human being qualities Is suggested. Such a 
system would exhibit the qualities of the perfect human personality. It would 
be the perfect assistant, always trying to understand the needs and Intent of 
the human and never blaming the human when It falls. It will forgive the 
human's errors, and will not require difficult feats of memory, mental 
agility, or physical dexterity. It will be exceedingly "sharp" In that there 
will be many senses available such as vision and voice input and output. In 
addition, this perfect assistant will be brilliant when it comes to knowing 
details about the underlying system, its state, and the likely consequences 
of alternate courses of action. 


k,7 AUTOMATIC CONFIGURING COMPUTER BUS A>^D OPiSATlNG SYSTEM 
The overall operations data management system architecture Is depicted In 
Figure 4-4. It Is a hierarchical structure consisting at the highest level of 
an operations data management system computer (ODHSC), a high speed computer 
network or busing system which Interconnects the ODMSC to the lower level 
functional elements or subsystems^ and the operations subsystem computers 
(OSSC). The OSSCs are completely self-contained and self-sufficient with 
their own control and operating system. The status of each subsystem can be 
monitored and managed by the ODMSC. The local area network (LAN) 

interconnecting the subsystems and the ODMSC is redundant. The LAN is of the 
Ethernet or Hyperchannel class. 


4 . 7.1 GENERIC ARCHITECTURE FEATURES 

To be cost effect ive^ it is imperative that the overall system architecture 
encompass approaches and techniques which can be applied throughout the 
system; i<e. the problem must be considered from a general point of view and 
the use of special purpose concepts or devices within a given computation 
system must be avoided. The computation systems shown in Figure 4-4 are 
identical except for the number or amount of resources employed at -7 given 
level or subsystem. To accomplish these generalized objectives, the data 
management and computer systems must possess the following salient features: 

o Be capable of adapting to Various throughput demands. This 
implies that each computer contain varying resources, i.e., 
processors (P), memories (M), and input/output (I/O) units as 
indicated In Figure 4-4. 

o In each local computer, resources must be configured either to 
achieve high reliability or to provide automatic fault detection 
and isolation to minimize system down time. 

o With the resources available to accomplish the goals of items 1 
and 2 above, reconfigure the system to provide trade-offs in 
throughput and reliability; i.e., the system should be able to 
degrade in a graceful manner as opposed to an abrupt outage. 

o To minimize life cycle costs (developmental, operational, 
maintenance, logistics, training, et cetera) a common set of 
rudimental elements, such as processors, memories and 
input/output units must be provided which can be used in all 
Space Station computational systems. 

o The basic architecture must be capable of accepting the latest 
technological innovations. 
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o A generalized architecture and common computing devices imply 
standard software and spftwttre development tools; i.e., higher 
order languagesy compilers^ translators, assemblers, operating 
systems, et cetera. 

V.7.2 RELIABILITY, COMPUTATIONAL CAPACITY AND DEGRADATION 

To gain an understanding of the trade-offs which can be made in reliability, 
computational capacity, and degradation (items 1 through 3 above), a specific 
example will be helpful. 

Consider an idealized model, as shown in Figure A-5, which contains three 
stages: memory, processor, and input/output. As shown, each of these stages 
has been replicated N times. For this illustration, it is assumed that an 
element in any stage can be interfaced and used with any element in the 
succeeding stage. No consideration in the model is given either to how this 
might be accomplished or to the effect it might have on the parameters of the 
model. In other words, a perfect interface or switching device is assumed. 

Figure k-6 shows the parameters reliability, computational capability, and 
degradation plotted as a function of operating time. Operating time has been 
normalized to the mean time to failure of a simplex system. Computational 
capability is expressed in terms of the throughput relative to a simplex 
system. In the figure shown, each stage has been replicated six times (a six 
processor system) and five failures are allowed in any one or all stages, 
I.e., only one processor is required to be functional to have an operational 
system. A further simplifying assumption Is that the reliability of each 
element in the three stages is equal. 

4 . 7.3 MODULAR ORGANIZATION 

Figure 4-7 indicates the effect of modularity in a six processor system on 
reliability, computational capability, and graceful degradation. For m*l 
through 3, the total computational capabilities are 5.5, 8.0, and 10.25 

respectively times that of a single processor; the operating times when the 
last system can be expected to have failed are 2.45, 3.8, and 4.6 times that 
vr a single processor. The total computational capability of an idealized 
system is dependent on the time the system is expected to be operational. 
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This follows directly from definition and Is clearly Indicated In the figure. 
The effect of modularity on degradation^ computational capability, and 
r'^l lability is clearly indicated by the sets of curves: A six processor 

system with m*3 yields more than 1.7 times the computational capacity obtained 
from six parallel processors (m*l) and It Is expected to be functional more 
than 2.1 times as long. The upper set of curves indicates the effect of 
modularity on reliability. (Appendix C gives a more detailed treatment, 
derivation, and discussion of the effects of modularity on throughput, 
degradation, and reliability.) 

MULTIPROCESSOR TOPOLOGIES 

From the above discussion, it is clear that modular organizations can improve 
throughput and allow a system to gradually degrade in contrast to an all up or 
all down situation. A so-called multiprocessor organization can provide the 
attributes of optimum computing capacity and gradual degradation. A 
multiprocessor is defined herein as follows: (This definition, as well as 

much of the basic material can be found in (Enslow 1)}. 

o It must contain two or more central processing units. In the 
general sense, these may or may not be identical or have 
approximately the same capabilities, but for logistic reasons, 
the basic processing elements in the Space Station will be 
assumed to be identical. 

o Some portion of main processor memory must be shared and 
accessible by all processors. All memory may be common, but some 
private memory may be highly advantageous. Sharing total memory 
may compl icate some of the system problems. 

o Input/output access, including channels, control units, and 
devices must be shared as appropriate. 

o There must be a single well integrated operating system in 
overall control of all hardware and software. 

o There must be Intimate interaction at both the hardware and 
software operating system levels: At the system software level 

in the execution of systems tasks; at the program level for the 
execution of portions of the same urograms' by several processors 
in turn and the execution of an independent task of a program on 
a processor other than the one executing the main task (the 
ability to move a Job); at the data set level; and at the 
hardware interrupt level. 


Hardware and software interactions depend both on the systems software and 
operating procedures and the physical configuration and Interaction between 
the various elements. ^-33 



For an operating system controiling the complete system to be effective and 
reliablei several hardware features should be present. These include: 

o There should be a hardware "lock" that can be set to prevent 
entry by another to ensure the integrity of tables or data sets 
while being accessed by one processor. 

o There must be a capability for variable logical addresses or 
names of processor channels, memories, and devices rather than 
fixed physical addresses. 

o A processor must have the capability to signal or interrupt 
another to request that It perform a certain function or to 
determine if the other processor Is still functioning. This may 
be accomplished with an interrupt or a mailbox and polling 
message passing procedure; i.e., a "soft- Interrupt". 

o If a processor has failed, another processor detecting this and 
wishing to reschedule the work in progress on the down machine 
must be able to access all the Information necessary to do this 
even if some of that data is within the processor itself. 

o It may be necessary to have the ability for one processor to 
start or restart another no matter what state the latter may be 
in as long as it is still operational. 


In the past, systems have been defined and developed with varying topologies 
of the interconnecting networks between the various functional elements. 
There must be several groups of multiple paths, either paths present 
physically at all times, or logical paths created by the connection network on 
an "as needed basis." These paths must provide the following capabilities: 

o Any processor can control and transfer data to and from any 
location In memory. (It may be convenient for each processor to 
have a small amount of private memory.) 

o Any processor can pass control commands to any I/O channel 
control ler. 

o Any I/O channel can access any location in memory. 

o Any I/O channel can control and transfer data between the central 
memory and any of its appropriate I/O devices. 

These interconnections must provide for total resource sharing. 


Typical examples of various types of interconnecting schemes between 
processors, memories, I/O channels, and devices are shown in Figures A-8 
through A-13. Figure ^-8 shows a single bus arrangement which is time shared 
between the elements. Figure A-9 Illustrates a multiple time shared common 
busing system. Figures ^-10 and A-11 illustrate another scheme for connecting 
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Figure ^-8. Time-Shared/Common-Bus System Organization-Single Bus 



Figure hS. Multiple Time-Shared/Common-Bus System Organization 



Figure 4-10, Crossbar Switch System Organization 
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•ny element on the bus to any other element. Such a scheme is known as a 
crossbar and has been used in such systems as Burroughs D825 (AN/GYK-3)* 
Figure i|-10 shows a single crossbar switch between processors^ memories, and 
I/Os, while Figure ^-11 shows a secondary crossbar switch between the I/O 
controllers and the I/O devices themselves. Figure i»-l2 illustrates a 
multiport, multibus memory system organization where each processor and I/O 
element can access any memory module through alternate buses. In Figure ^-13 
the multiport, multibus concept has been combined to obtain common shared 
storage (Mq and M^). The above illustrations and discussion serve to indicate 
that many different interconnecting schemes are possible and have been 
considered; each has Its advantages and disadvantages and the one which should 
be selected for use with a particular system depends on the overall goals and 
objectives of that particular system. 


There are three basic organizations and modes of the operating system 
executive of a multiprocessor: 

o Master-slave 

o Separate executive for each processor 

o Symmetric or anonymous treatment of each processor 

(Enslow 1) gives a very good treatment of these types. A summary of his 
account follows. 

if. 7.^.1 Master-Slave 

The master-slave mode may be dictated by the different characteristics of 

processors in the system and may have one processor designed especially for 
supervisory control and dedicated to that function. The primary 

characteristics of the master-slave mode of operation are summarized below: 

o The supervisor always runs in oniy one of the processors that is 
selected. This processor may be of special design configured 
Just to run the supervisor or it may be similar to all of the 
others in the system. If this approach were selected for Space 
Station, the supervisory processor would be Identical to the 
other processors in the system. 

o It is not necessary that ail of the supervisory routines be 

written in reentrant code, since only one processor will be 

executing them. Reentrant coding will still be necessary for 

some of the common routines that are used recursively or are 
subject to multiple activations. 
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There Is no problem of conflict or lock-out of executive tables, 
since only one processor will be accessing them* 

o The system is subject to catastrophic failure if the master 
fails. Restart can occur using another processor as the master. 

Also, special designs utilizing fault tolerant techniques are 
possible. 

o The system is inflexible in that it has one main processor and 
one or more satellite processors. 

o The master must execute its supervisory and executive functions 
fast enough to stay ahead of the demand; otherwise, inefficiency 
results. 

o Generally, the master-slave approach contains simpler hardware 
and software structures but does not have as much flexibility as 
the other schemes. 

k.T.k.2 Separate Executive 

In the separate executive for each processor mode, memory is shared and there 
is no need for completely separate copies of the coding for the operating 
system for each processor. Each processor operates autonomously and executes 
all of Its own executive, supervisory, and support functions just as If it 
were a stand-alone processor. Each task is assigned to a particular processor 
and runs to completion on that unit. The characteristics of this type of 

operating system organization and operation may be summarized as follows: 

o Supervisory functions are executed by each processor as required 
to service its own needs and those of the program assigned to it. 

o Because several processors are executing it, the code for the 
supervisor must be reentrant, or private copies will have to be 
loaded for each processor. 

o There will be less conflict on system table lock-outs, since each 
processor will have its own private set. There will not be as 
many common executive tables. 

o The total system Is not subject to catastrophic failure due to 
the failure of any one processor; however, recovery and restart 
of the work In progress on the failed unit will usually b«5 very 
difficult. 

o All I/O operations for a given task are executed by the processor 
to which it is assigned. 

o i/0 interrupts are directed to the processor initiating the I/O 
operation. 

o Each processor has its own private set of I/O equipment, files, 
et Cetera. 

o Sharing of auxiliary storage is not possible without special 
coding. 
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o Efficiency can be low if one processor has several IOit0 Jobs In 
progress while others sit idle. 

o Reconfiguration of I/O may require manual switching* 

Svimietric or Anonymous Processors 

The most “pure" hardware configuration for a multiprocessor is an ensemble of 
Identical processing units containing identical processors, shared common 
memory, I/O channels, and I/O devices which can be treated symmetrically. 
Evpry processor can be equally effective in executing the supervisor and, for 
efficiency, this is what is done. The executive "floats" from one processor 
to another. There are certain executive functions that are inextricably 
associated with a task and are best executed by the same processor that is 
executing the task; however, there are many others such as the handling of 
Interrupts for asynchronous I/O operations that can be handled by any 

processor. The primary motivation for this mode of operation is the overali 

0 

system efficiency achieved in spite of the difficulties to be considered 
later. Perhaps the most interest and attention has been given to this mode of 
operation. 

The basic characteristics of symmetric operation are as follows: 

o Each processor executes those supervisory functions inextricably 
connected with the task that it Is currently executing and those 
functions necessary to get a new task when the current one Is 
interrupted or completed. Any processor can perform all or most 
of the general purpose functions. 

o Because of the anonymity of processors and the symmetry of their 
treatment, a task may be executed on various units during Its 
progress through the system. On successive executions, a 
different set of processors can be utilized. 

o Overall system control "floats" between the processors. 

- The one In control of system tables and functions such as 
scheduling is called the executive processor. 

- Only one at a time can be the executive to prevent conflicts. 

- Each processor may be assigned a priority. 

Although only one processor Is the executive In overall control, several 
processors may be executing the same supervisory code simultaneously and the 
coding must be reentrant to provide for separate copies for each activation. 

There are very real problems of conflict which must be dealt with in the 
access of tables and data sets. These include: 
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o EKcesstve lockouts of system control tables can greatly affect 
overall efficiency. 

o Lockouts on each data set are essential and the time delays have 
to be accepted since one processor might try to access a record 
being niodl fled by another. 

There are several advantages of symmetric or anonymous executive control of 
multiprocessor systems. Some of these are: 

o It can provide graceful degradation. 

o Better uptime potential than separate backup system^ 
provided that system is designed properly. 

o Only way to achieve real redundancy. 

o Most efficient use of resources. 

Although this organization is the most aesthetically appealing concept, It Is 
the most difficult to realize and most systems utilizing It have had to back 
down when they have become operational; e.g., IBM’s 9020 system for the FAA. 

Factors In Topology Selection 

Some of the basic functional capabilities which must be considered and 
provided for In a multiprocessor system are: 

o Resource Allocation and Management 

- Memory Allocation and Control 

- Scheduling and Dispatching 

o Processor Intercommunications 
o Abnormal Termination 
o Processor Load Balancing 
o Table and Data Set Protection 
o Input/Output Load Balancing 
o Reconfiguration 
o System Deadlock 

The attributes, alternate approaches, and factors which must be decided in the 

design of a multiprocessor system have been discussed above. A very fertile 
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area for future research Is studying and evaluating the various trade-offs to 
arrive at an efficient computer system for Space Station* In the past, 
considerable effort and cost were devoted to developing Individual elements 
for the multiprocessor system; I.e., processors, memories, and Input/output 
units, etc. Vllth today's technologies, these devices are readily available at 
a very reasonable cost, and the majority of effort and monies can be devoted 
to system approaches, configurations, and software control techniques. 

4 . 7.5 DESIRABLE CONCEPTS FOR SPACE STATION 

Although considerable Investigation and research are required (and highly 
recommended) within the framework of the previous discussion, the 
characteristics desirable in the Space Station computer can be defined and an 
approach broadly considered. 

Each computer in the Space Station operations, ODHSC, OSSC, and missions 
applications functions is a multiprocessor. Each processor Is a fully capable 
stand-alone computer with its own operating system. Each processor has the 
single minded goal of working a set of Jobs that: It will obtain from an 
external stack In a designated memory module. Each processor will have a 
multitask operating system and interrupt capability so anytime there Is a need 
to await some external event, such as an I/O completion, the processor can get 
another task. Tasks are placed in the memory queue for execution by whichever 
processor is available next. This has inherent reliability advantages without 
a sacrifice in throughput. Should a processor fall for any reason, or simply 
be removed, the software awaiting execution does not realize any change in 
configuration. By employing the concept of process objects that has received 
recent attention with the Intel Corporation's IAPX-432, a complete 
Identification of the required I/O, data files, and state can be included In 
each "task." By storing the state data when an Interrupt occurs. It Is not 
even necessary that interrupted processing be resumed by the same processor. 
This concept was first demonstrated on the Navy's AN/GYK-1(V) 0825 ARCH 
multiprocessor In 1962 (Thompson 1). Advances in microprocessor technology 
make this concept attractive for the highly functional, redundant, repairable, 
and modular expandable computer desired for Space Station. 


^•7.5.1 Critical Tasks 

With the concept of fully describing each process object In terms of Its 
needed resources^ critical tasks can be flagged for multiple eKecution. In 
such situationsi an accepting processor would leave a copy on the stack and 
identify that It was being executed# As other processors became available, 
process objects could be executed the required number of times and eventually 
removed. Results wquid be placed In the designated location, probably 
distributed among several memory modules. Thus redundant, voting logic 
execution could be selectively executed without a commitment to excess 
resources when not required. A failure of a processor would be so reported to 
the subsystem performance monitoring subsystem for annunciating and subsequent 
corrective action, which would likely be the scheduling of maintenance at the 
next available shift. Some computational capability would be lost, but 
re I i ab i I i ty wou I d not > 


With the advances in mlcrocircul try, many sophisticated butit-in test concepts 
are evolving. In many instances, the triple redundant voting logic is not 
necessary. The only requirement is that faults be detected in time to perform 
the computations over again on a different processor. For an overview of 
design for testability, see (Williams I). 

^•7 '5.2 Analytic Redundancy 

An interesting concept for Space Station fault detection is the notion of 
analytic redundancy, discussed In (Deyst 1). An example of how this concept 
might be employed by the subsystem performance monitoring subsystem would 
proceed as follows: 


The performance monitoring function could obtain positional 
information from both the navigation subsystem and from the mission 
data. It is assumed that in the mission partition, some image 
processing and registration capability exists. it is also assumed 
that the image processing system has access to some ground control 
points. In order to assemble completely documented data sets, there 
is a correlation of position and the acquired images. The on-board 
data base could correlate the ground control points to a specific 
position and time and this could be compared with the data from the 
navigational system. While this might be too process intensive for 
normal navigation, it provides a means to monitor the performance of 
the navigation system using analytic redundancy. 


^•7*5*3 Fault Tolerant Memory 

An additional point of Interest for further development of the computer system 
is fault-tolerant memory. Soft memory errors are induced by alpha particles^ 
cosmic radiation, and other random sources. Characteristics of a fault 
tolerant memory are presented in a paper by (White 1). The effectiveness of 
this approach is illustrated with numerical examples and the use of a 
mathematical model. This same memory architecture |s incorporated in the NASA 
NSSC- 1 1 . 

^1.7.6 COMPUTER ARCHITECTURE DEVELOPMENT NEEDS 

In summary, it is highly recommended that a research and developi.ient task be 
instigated to perform trade-offs in the various network configurations, 
executive control schemes, resource ass i|inment and allocation, 
reconfiguration, et cetera, to arrive at an efficient multiprocessor 
configuration which satisfies Space Station requirements. With today's 
technology and available equipment, such a study could readily treat the heart 
of the problem; i.e., configuration and control techniques, rather than in 
having to design and fabricate specific elements such as processors, memories 
and i/Os to demonstrate an architiif ture. 

i».8 SPACE QUALIFIED LARGE SCREEN DISPLAY 

The degree of automation envisioned for the Space Station tends to reduce the 
need for personnel to be located at stationary positions. It is likely that 
some fair degree of mobility will be the norm for Space Station personnel. 
Yet, with the large number of imaging sensors available, a means of displaying 
the images that will provide good resolution at a distance is required. Large 
displays have been effectively used for ground-based launch control and 
payload operations centers. They will likely be needed in the Space Station. 

Space Station space will be much larger than historical spacecraft. Before 
Space Station, there was no need to develop space qualified large screen 
displays. Consequently, there is little experience available. At this point, 
no single technology is favored. The oil film does not seem suitable for the 
microgravity of space. Experience with electrophoretic and light valves in 
space IS almost nil. Plasma has always been limited by lack of grey scale and 
approaches at color have not been very successful. Large folded CRTs have not 
been implemented for various reasons. 



i».9 QUALIFICATION SYSTEM FOR DATA SYSTEM COMPONENTS 

The correct consideration of space qualified components will have a major 
impact on life cycle cost. The changing role of manned presence and 
Indefinite life call for new considerations of reliability and 
maihtuinab! I Ity. Technological advances of commercial components should not 
be forfeited because of excessive space qualification processes. Yet, because 
of safety concerns, especially outgassing of materials, commercial products 
cannot be used carte blanche. 

One alternative is to include a space equipment test facility as part of the 
research program. The best method of determining if a commercial part may be 
space qualified is to simply take it out into space and test it. This method 
not only eliminates the excessive space qualification processes, but may also 
reduce the life cycle cost of the Space Station. 

A facility as described would be incorporated into the Space Station and would 
be highly instrumented for EMI, outgassing, and any other contaminants that 
are likely. The technology required would be the development of a complete 
concept for 1) handling such testing, 2) the generation of guidelines and 
standards for use by experimenters and users that had to build components for 
use on the Space Station, and 3) the initiation of an education and 
information dissemination process to acquaint potential users with the 
critical factors. 

i».10 DIRECT BROADCAST 

Trends in satellite communications technology can be predicted with reasonable 
certainty over the next five years. 

Body~stabi 1 ized platforms allow comple,< antennas to be directed toward the 
earth and larger solar-cell arrays to be oriented toward the sun. Energy 
conversion and storage will become more efficient and sophisticated, and more 
power will thereby become available. Higher frequency bands will greatly 
increase capacity. Multibeam antennas and improved interconnectivity of 
antennas and transponders will allow flexibility in assigning capacity to 
different geographic areas. Reusable manned launch vehicles — the Space 
Shuttle — should reduce launch costs, permit controlled tests of new 
technology, and eventually make possible the repair of satellites in orbit. 


To Increase capacity any significant amount, future satellites will employ 
several simultaneous uses of the same frequency band. Furthermore, In order 
to locate earth stations close to traffic sources. It may be advantageous to 
operate In one of the higher frequency bands, where Interference is less of a 
nroblem. Fortunately, these two requirements go hand-in-hand, because 
frequency reuse is obtained by spatial separation of the satellite antenna 
beams, and beam isolation increases with frequency, for the same size antenna. 

The use of higher frequencies will make beams more directional and should 
permit closer user spacing. Development of antenna s idelobe-suppress ion 
techniques will also help. The number of spacecraft In orbit could be reduced 
if varied services were combined on multipurpose space platforms. Aside from 
the serious technical problems that this last solution presents and the 
ensuing unavoidable reduction of orbit-spectrum capacity, it will require 
agreement among diverse institutions, with possibly opposing Interests. 

4.10.1 TECHNIQUES FOR FORMING RAPIDLY SCANNED BEAMS 

A number of techniques exist for forming rapidly scanned beams. The simplest 
approach is to use a parabolic reflector having multiple feed horns in an 
array configuration. Each feed horn, when singly excited, produces a main- 
lobe radiation pattern that Coincides with the intended coverage area on the 
ground. Because all the reflector's power is fed into a single horn, 
switching (which must be performed at high power levels) becomes lossy and 
slow. In addition, adjacent beams must overlap at their -3 db points for 
full -area coverage, necessitating an undersized feed horn that reduces antenna 
gain because of spillover losses. Significant cross-coupling loss into the 
adjacent feed horns further reduces reflector antenna gain. An alternative 
method is to form a beam by simultaneously feeding the center and adjoining 
horns at reduced power levels. This reduces spillover and cross-coupling 
losses, but complicates the feed structure and does not alter the fact that 
the center horn must still handle most of the antenna's power. 

Another technique is to use a phased-element- array, where a digital phase 
shifter is employed in each element. The phase shift is controlled by high- 
speed logic, and losses are overcome by low-power transmitters at each 
element. To make the array's gain large, either the number of elements or the 
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gain of each element can be Increased. As the number of elements increases 
over 100, the additional number of elements required to gain more decibels 
becomes worrisome. For example, adding $0 elements to a ten'element array 
will increase the gain from 10 to 20 db, but 900 additional elements are 
neqded to raise the gain from 20 to 30 db. 

There are imaging techniques, similar to classical optics, that allow the 
physical size of the elements to be greatly reduced. The patterns produced by 
the elements are magnified through a system of lenses and projected onto a 
single large aperture. 

A newly devised satellite antenna, described later, would allow a scanning 
beam and several fixed spot beams to operate simultaneously. Thus we envision 
that a high-capacity station could be constructed by employing several fixed 
spot beams centered on the major users, and a scanning beam that operates on 
the orthogonal-polar izat ion principle, to provide service to the remainder of 
the country through TDM. The fixed spot beams would operate in a satellite 
switched time-division multiple access (SS/TDMA) format. The scanning beam is 
also connected to the satellite switch so that all possible interconnections 
among the spot beams and the scanning beam are available. 

This hybrid satellite of fixed and scanning beams Is used as a model for the 
example system that is described here. Phase shifters, following the 
preamplifiers, point the antenna beam toward the earth station that is 
transmitting at any given moment. They change state very rapidly, consume 
very little power, and have relatively low insertion loss. Once the signals 
are phase shifted to produce a coherent signal, that signal is no different 
than any other spot beam as far as the satellite is concerned. It can be 
down-converted, passed through the satellite switch, and directed into any 
spot-beam down link. 

i^.10.2 SCANNING SPOT BEAM 

A scanning spot beam requires many low-noise amplifiers, digital phase 
shifters, and power amplifiers. Considerable effort is being devoted to the 
1^ GHz preamplifiers and to 12 GHz power amplifiers for other applications, 
and we will not discuss these in any great detail here. The system 
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requirements for the phase shifter make It different from anything that Is 
commercially available. 

An experimental digital 4-b|t phase shifter that operates at 12 GHz was 
constructed recently by Bernard Glance of Bell Laboratories. It might satisfy 
the system requirements for a scanning spot beam— compactness and low 
transmission loss. The circuit was fabricated in a microstrip line using 
copper evaporated on a silica substrate. The RF and driver circuits are 
enclosed in a single package to minimize switching time. 

The entire phase-shifter circuit consists of four cascaded microstrip cells 
providing phase shifts of 90, 180, ^5, and 22.5 degrees. Each cell Is made of 
a 3 db branch- line coupler whose coupling arms are connected to open sections 
of a transmission line, with a P|N diode in each line to change Its electrical 
length. The cells are identical except for the position of the diodes, which 
are positioned to give the required phase shift. 

It is especially important that the phase shifters be capable of changing 
state very rapidly, so that no large penalty Is paid in overhead from the 
TOMA. It is also necessary that the phase shifter consume a very modest 
amount of dc power, since more than 200 of them would be needed for the two 
Independent scanning beams. 

The scanning spot beams must be controlled to move in a certain sequence. For 
the low earth orbiting Space Station, this must include the orbital dynamic 
timelines. The time spent at each location should be proportional to that 
area's traffic needs. Such beam times at a given location can be as little as 
1 or 2 microseconds. To update 100 ^-bit phase shifters in 1 microsecond 
requires a data rate of 400 Mb/s. Clearly, to attempt such updating from the 
ground would be foolish. Furthermore, once the scanning sequence started it 
would repeat many times before changing. Changing the sequence is only 
required as individual earth station's capacity requirements change. Thus, it 
appears best that the controller be on-board the Station. 

Thanks to today's semiconductor technology, one can readily construct a 
sequencer that can cyclically perform the simple task of determining where the 



beam should point next and for how long. One way Is by a table look-up that 
contains the beam's locatlon-to-phase-shlfter settings along with a simple 
counter that is set each time a new beam is formed. The counter merely counts 
clock pulses down to zero> which starts the process to move the beam to the 
new location. The clock Is reset to the new count for that location and the 
process continues. 

If a data channel to a master control station Is provided^ then all requests 
for changes In service could be monitored. The master controller could honor 
requests for changes In service by updating the sequencer for the scanning 
beam, and in a separate channel ^ let it be known to all earth stations that 
the sequence has changed. 

If an earth station were to misinterpret the Information from the master 
station and transmit out of turn, a small disaster might occur. Therefore, it 
would be wise in granting new requests to allow changes in the sequence as 
seldom as possible, perhaps by having a number of preassigned slots for each 
earth station. Such slots change very rarely, but additional service requests 
could be handled by having a pool of circuits (near the end of the sequence, 
for example) available strictly on demand. 

It has been shown that a scanning spot-beam satellite is a blending together 
of two technologies: TDMA and spot-antenna beams. Both will appear in 
various forms in the next generation of commerr, iai satellites. However, there 
are no commercial systems now underway that would utilize rapidly movable 
spot-antenna beams as discussed in this report, and their eventual use in a 
satellite is very difficult to predict. 

Several advantages of a scanning spot-beam satellite have been pointed out, 
including high effective isotropic radiated power, high capacity, high 
trunking efficiency, and good utilization of the orbital arc. 

The disadvantages could include high-speed channel operation (600 Mb/s); 
commercially available TDMA modems operate at only one tenth this rate today. 
Thus, it will be necessary to develop high-speed and relatively low-cost 
modems before systems of this nature become viable. There appear to be no 
fundamental reasons to prevent high-data-rate TDMA operations. 


Another problem Is the development of a scanning spot-beam transponder for the 
satellite. ft has been shown that all of the necessary components exist to 
assenrf}le such a transponder, but satellite vendors proceed cautiously —for 
obvious reasons. Before building such a satellite, a great deal of 
developmental effort would be required in space qualifying and life testing. 

For example, PIN diodes suitable for a switch that could be used to reroute 
traffic among beams in a multi-beam satellite have been available since 
SS/TDMA was first discussed. Another example of conservatism comes from the 
very slow rate at which TWTs are being replaced by solid-state amplifiers. 
Implementation of scanning spot-beam systems reasonably can be estimated as 
several years away. 

For very large trunks, one would probably choose to employ individual fixed 
spot-antenna beams. Also, a scanning spot beam would only be of limited use 
for broadcasting where the same message usually goes to a large number of 
users. The scanning beam would thus have to keep repeating a single message 
to different geographical areas. It is equivalent and undoubtedly simpler to 
transmit the message only once to a larger area. 

However, for cases where several different messages are broadcast 
simultaneously to dispersed geographical areas, scanning spot beams could be 
employed, and it appears that their most useful application will be to provide 
commun icatio’^s among many small, geographically dispersed terminals. Examples 
include mobile communications, and the private networks, used by large 
businesses, where several networks share the same satellite. A scanning spot- 
beam could also be useful for trunking moderately large bundles of traffic, 
say about 1000 equivalent voice circuits. 
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SECTION 5 
RECOMMENDATIONS 


A major objective of phase one of this study was to identify data system 
technology elements that have a high potential for reducing life cycle cost of 
the Space Station. A wide range of factors In the total Space Station system 
implementation, operations, applications, and data systems techniques was 
ouched upon during this study. There was a concentration on different 
approaches that might require long lead time development for fruition. 
Generally, concepts were considered because of a recognized potential system 
problem or because a concept offered an intuitive high payoff. It must be 

emphasized that this study is indicative of only the opening moves in what 

will unfold as an interactive epic spanning generations. Only the very best 
of the concepts should be the subject of extensive research and development. 
However, there is usually no finite line of demarcation between what is and is 
not likely to be fruitful. Rather a continuing process of further 
investigation and decisions on a case-by-case basis will be required. Some 
suggestions to an approach for selecting additional investigation as a 
function of available resources will be included in this section. 

5.1 TECHNOLOGY INFLUENCE 

The underlying idea that investment in technology will improve the 

implementation cost ratio is sound. In practice, the strategies are more 
complex. The model of the technology relationship to the Space Station 

system and the global environment is only vaguely defined. It is implicit in 

the decision making process but has not been committed to any formalism. 
Perhaps the first recommendation should be to formalize those relationships. 

5.1.1 TECHNOLOGY MODEL 

This era of rapid technological advances is primarily a result of economic 
pressures and an awareness by the world's population that technology offers a 
large return on investment. This environment adds a new dimension to the 
systems engineering of large complex systems with a long elapsed time from 
concept to operational deployment. As a system is refined from general 
requirements to specific designs, external environmental changes can 
invalidate earlier optimization decisions. The trick for success is to either 
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work with sufficient abstractions at each stage In the development process sp 
that environmental variance will remain within the boundaries of the 
abstraction, or to be skillful at predicting the environmental state for the 
time frame of interest. A generic model of the relationship of technology on 
the environment is presented In Figure 5’l« 

This model is presented as a rudimentary concept. No claim of Its validity is 
advanced and no supporting evidence is offered. The logical relationship will 
be briefly stated* The referenced numbers correspond to the numbers on the 
board activity that take place in the environment. 

5 . 1.1.1 Planned Technology Programs 

The degree of emphasis and funding of technology programs (1) will Increase as 
technology advances. There exists some coupling of success and economics to 
(I) but it Is not explored at the first level. 

5 . 1.1. 2 Technology Advances 

This is the unknown of interest In this model. 

5 . 1 . 1.3 Cost Effective Technology 

This is a goal of a program such as this. As technology in general advances, 
there will be a larger pool of cost effective technology upon which to draw 
for system implementation. Of course, the next links are dependent upon the 
technology being applied or permitted by the specification to the system. 

5 . 1.1. if Features of System 

Technology advance wi 1 1 also enable enhancement of the system capability. It 
can do more things for more applications, or do them better. 

5 . 1.1. 5 Component Performance 

The performance of individual components will improve as technology advances. 
These performance improvements may be manifested in faster operation, lighter 
weight, less power consumption, or a variety of other parameters. Generally, 
this coupling has some natural value that is not strongly influenced by other 
factors in the model. 
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Figure 5”1. Impact of Technology on Users and Cost 



r 


5 . 1 . 1 .6 Initial Cost 

The Initial cost of a system will be positively coupled to the features of the 
system and will be reduced by the influence of cost effective technologyf The 
complexity (8) of the system will also increase initial cost. Generally, the 
initial system design optimization involves a trade-off between initial and 
rework costs. Sayings In initial cost will incur greater rework cost. 

5. 1.1. 7 Rework Cost 

This is a necessary activity for long life systems. Changes in requirements, 
technology, and the environment become too drastic before the planned useful 
life of a system runs out. Rework can be a cost effective method of 
stretching useful life. This concept is now well recognized with catch 
phrases like PPPI, Pre Planned Product Improvement. 

5 . 1 . 1 . 8 Complex! ty 

Complexity is often the price paid for additional system features (h) and 
capability (9). It increases both initial and rework costs. 

5. 1.1.9 Capability 

Capability is distinct from features. Capability is the measure of the amount 
of the functions the system is able to perform for a data system. Parameters 
such as throughput, millions of instructions per second, or storage capacity 
are representative. Capability will be positively increased as component 
performance (5) increases. It also is positively correlated with complexity 
( 8 ). 

5.1.1.10 System Lifetime 

System lifetime is Influenced by technology advances. This is the time a 
system will function without wearout. Obsolescence is not considered in (10). 

5.1.1.11 Technology Base 

The technology base is the industrial, economic environment. It accounts for 
more than know how of technology advances (2). This component (11) accounts 
for the breadth and depth of the means of production. 
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5.1.1.12 Technology Maturity 

The rate of technology (naturlty increases as the technology base expands. 
There are more users of technology to discover needed Improvements and whether 
they are economically worth pursuing. 

5.1.1.13 Technology Dissemination 

As technology matures more people ore aware of It. This In turn increases the 
technology base. 

5, l.l.lA User Ability to Use Benefits 

The ability of a user to utilize benefits Is dependent upon technology 
dissemination. An example of this correlation Is image data and 
microprocessors. A few years ago, widespread availability of digital Images 
would not be valuable to many users because they would not have the systems in 
place to accept digital formats. With the widespread dissemination of 
microprocessors and their cost reduction, virtually any user with a need for 
image data could accommodate the digital format. 

5.1.1.15 User Acceptance 

Another Important factor in a successful system is user acceptance. This will 
be strongly influenced by his ability to use the benefits (lA). Acceptance 
will also be negatively coupled with cost to the user (20) and the benefits 
(16) he receives. 

'5.1.1.16 Benefits to User 

These are the end results of features (A) and capability (9) of a system. 
Only those that benefit the user will positively influence his acceptance. 

5.1.1. 17 Number of Users 

The number of users will increase as system capability (9) and user acceptance 
(15) Increases. As the number of users increase, there will be more common 
functions (19). Operating costs (18) will increase as the number of users 
increases, but amortization (21) will be spread over a greater number. 


5.1-M8 Operating Costs 

Operating cost will be increased by the number of users. The availability of 
cost effective technology (3) will reduce operating cost. Operating cost will 
be positively coupled with the cost to the user. A more tenuous relationship 
exists between features {k) and operating costs. Features (l|) should 
diminish operating cost, but could Increase it. 

5 . 1 . 1.19 Common Functions 

Common functions are things that many users need. Technology advances permit 
greater utility of devices (flexibility). As the number of users increases, 
there will be increased Intersection of the things needed to be accomplished. 
The result Is a decreased cost to the user. 

5.1.1.20 Cost to User 

This is the actual cost to a user. Artificial Influence such as through 
surcharge or subsidy is not considered. It is based upon operating cost (18) 
and amortization (21). As cost to user diminishes, user acceptance will 
increase. 

5.1.1.21 Amortization 

This is the accounting distribution of the capital costs, Initial (6) and 
rework (7) over the lifetime of the system. As the system life (10) 
increases, per unit amortization, would be passed on to the user, 

diminishes. 

5 . 1.2 SELECTION CRITERIA 

The selection criteria for a particular technology development project 
accounts for the following factors; 
o Worth of project 

o Time criticality of project 

o Cost of performing project 

o Environmental influence on technology 

0 Impact of lack of technology 

c R i s k 
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Worth of Prolect 

The worth vf a techriojogy Is an assessment of the potential benefits of having 
it. This has to be a discounted assessment because In some situations the 
worth is dependent upon the ultimate dt^pioyment mode or application of the 
system. In other cases, the worth is influenced by the availability or lack 
of alteirnat ives. 

5 . 1*2. 2 Time Criticality of Project 

In a budgeting process involving valuable resources, which may be dollars, 
personnel, or facilities, emphasis must be placed on those things that are 
needed first. Some very high potential projects may be excellent candidates 
for deferral If their utility will not diminish significantly by delay. 

5.1*2. 3 Cost of Performing Project 

This is a necessary factor. Absolute cost is not a driver In prioritizing 
projects, but may be a real life constraint. The measure of significance for 
selection is the cost benefit ratio where the br '’f.i is either the worth of 
the project or some weighted combination with thC; other factors. 

5 . 1*2. A Environmental Influences on Technology 

This is a factor for evaluating the necessity of investment In a long term 
technology. For some needed technologies, the natural forces of the market 
place may bring them along without specific impetus for a program like Space 
Station. 

5 . 1*2. 5 impact of Lack of Technology 

Some technology projects have considerable worth in terms of enhancements 
possible when the technology becomes available. Equally critical and possibly 
more so are those technologies that will have disastrous repercussions if they 
are not available. These often are the ones that are almost available and 
become integrally associated with the overall system design. Then when 
problems are encountered, the total system development is impacted. 

5, 1.2. 6 Risk 

Some technologies may be pivotal in terms of major design decisions. There 
may be competing approaches or there may be a heavy reliance on a technology 


that Is almost here. Additional development may be Justified to obtain 
greater certainty of availability or to provide an alternative. Sometimes 
Just being able to prove the principle will save considerable system design 
cost by removing the need to continue alternate concepts. 

5.2 TECHNOLOGY CONCEPT SUMMARY 

Many concepts involving different applications of exi sting ‘ technology of 
unproven techniques have been identified during this study. Some of these are 
identified in Table 5“1 with a cross reference to the paragraphs of 
discussion. 

5.3 ASSESSMENT OF TECHNOLOGY CONCEPTS 

All the technology concepts identified require additional investigation to 
fully assess this priority for development. The criteria can be applied 
analytically. However, a large number of the concept evaluations will be 
greatly Influenced by the emerging configuration of the Space Station as a 
result of other studies. Applying the time criticality criterion, the 
Judicious approach at this time is to defer temporarily further assessment on 
all but the following: 

o Total life cycle ground support 
o Architectural design 
o Automated command management 
o Self-organizing data bases 
o Human gateway 
o Technology model 
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Table 5-1 • Technology Concepts 


CONCEPTS 

PARAGRAPH 

REFERENCES 

Hierarchical Control 

2.2.1 

Virtual Architecture 

2.2.2 

Standard Interface 

2.2.3 

Overall Architecture 

2.3 

Separation of Operations and Mission 

2.3 

Asynchronous Architecture 

2.3.1 

Centralized Orchestration Architecture 

2.3.2 

Independent Kernal and Monitor 

3.2 

On-Board Logistic Management 

3.5 

Collision Avoidance 

3.6 

Direct Broadcast 

3.8 


4.10 

Asynchronous Session Access Protocol 

3.8.3 

On-Board Data Analysis 

3.9 

Quick Look System 

3.9.1 

Ground Requirement Management 

3.10.3 

4.2 

Total Life Cycle Ground Support 

3.10.1 

Ground Engineering Aids 

3.10.2 

4.3 

Ground Software Management 

3.10.5 

4.4 

Automated Work Planning 6 Scheduling 

A.l 

Automated Command Managenient 

^♦.1 

Self<"Organizing Data Base System 

^.5 

Human Gateway 

k.6 

Electronic Mimic Board 

^.6.11 

Large Screen Display 

^♦.6.1.2 
A. 8 

Automatic Configuring Computer Architecture 

^.7 

Qualification System for Data System Components 

4.9 

Technology Model 

5.1.1 
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APPENDIX A 

SPACE STATION DATA SYSTEM FUNCTIONS 

1. OPERATIONS 

These functions of the Space Station data system are required to provide a 
permanent inhabited Space Station independent of its mission requirements. 
These functions are operations control, cotrwnuni cat ions, and data management. 

1.1 OPERATIONS CONTROL 

This function encompasses all those data system functions necessary to 
maintain the Space Station in a survivable state. It includes the necessary 
redundancy management and either fail operational or fail safe modes to permit 
the long term survivability of the system. The major functions are: 
subsystem control, subsystem performance analysis, command management, 
attitude operations, orbital operations, and docking maneuver. 

4 

1.1.1 Subsystem Control 

This function encompasses the control and monitoring of each of the subsystems 
comprising the Space Station. The associated data systems with each of the 
Space Station subsystems are assumed to be a part of the specific subsystem 
and will generally be excluded from the functional requirements of the Space 
Station data system<i There wi V1 be interfaces to each of these subsystems, 
which are included for reference. 

1.1. 1.1 Life Support 

This subsystem provides for the special Integration and redundancies required 
of the environment control, medical, and interlocks to support human life. 

1.1. 1.2 Power 

This subsystem provides all the necessary power for the Space Station to 
survive and function. It may be subdivided into solar, nuclear, battery, 
backup, et cetera. 

1.1. 1.3 Attitude 

This subsystem will control the attitude and pointing of the Space Station. 
It includes determining pointing error and drift, the automatic maintenance of 
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the designated attitude^ and the determination of and execution of the 
necessary commands to alter attitude when such commands are received. 

1.1. 1.4 Collision Avoidance 

This function provides for collision avoidance by all methods practical 
including the tracking of known debris in the orbits of the Space Station 
system components and monitoring via both active and passive sensors for 
unexpected debris. These functions include the maintenance of required debris 
data bases, interfaces to ephemerides data for the spacecraft and other 
platforms such as OTV, real time signal processing and signature analysis of 
observed signals, annunciation, and display of resulting debris tracks and 
corrective action assistance information. 

1.1. 1.5 Environment Control 

This subsystem acquires the necessary environmental data and generates the 
necessary stimuli to maintain the Space Station artificial environments within 
the prescribed limits. These environments include those suitable for human 
occupancy and those required for experiment and application subsystems within 
the environment control subsystem, including temperature, heating and cooling 
supplement, atmospheric conditioning, light, and elements required to 
accomplish these functions such as cryogenic pumps, radiators, piping, and 
ducting. 

Ii.1.2 Subsystem Performance Analysis 

This function ensures that the subsystems meet their operational and 

performance requirements. This function includes the evaluation and 
maintenance of the subsystem performance and monitoring and controlling 
operations. This function generally will include the execution of models of 
each subsystem to determine expected performance; accesses to data bases, 
analysis routines, and fault identification aids; and interfaces to human 
operators for interactive query and diagnostic action. 

1 . 1 .2. 1 Life Support 

This function provides on-line evaluation and current status of all life 
support components including active elements, consumables, anomalies, and 
parametric excursions from expected values. 


1.1. 2. 2 Power 

This function provides on-line evaluation and current status of each power 
subsystem. It includes interfaces with built-in test functions, the 
application of test stimuli according to acceptable protocol, models suitable 
for accelerated performance and life predictions, performance prediction under 
Induced environment, consumable accounting, anomaly detection and 
annunciation, and identification of parametric excursions from expected 
values. 


1.1. 2. 3 Attitude 

This function provides on-line evaluation and current status of each attitude 
component and functional performance. It includes interfaces with the bui’it- 
in test functions, it also includes the monitoring of drift, other signatures 
such as power consumption, and individual attitude subsystem performance 
trends such as momentum build up, wobble^ and structural flexure. 

1.1. 2. 4 Medical 

This function provides on-line evaluation and current status of the crew. It 
includes the direct acquisition of physiological data from sensors attached to 
crew members and Indirectly acquired data such as from atmospheric exchanges. 
The function also includes medical assistance and models for monitoring and 
detecting performance deterioration or abnormal stress conditions. It could 
include individual Crew member physiological models, diagnostic aids and 
access to pharmacological data. 

1.1. 2. 5 Environment Control 

This function provides on-line evaluation and current status of the 
environment control subsystem. it includes interfaces with the built-in test 
functions. It also includes the maintenance of parametric history and the 
analysis of trends, deviations, and consumable status. It may include models 
for control optimization under stressed environmental conditions such as long 
duration radiation exposure at fixed attitudes, abnormal sunspot activity, 
abnormal heating from equipment usage, contingency operations, loss of 
components, and consumable shortages. 


1.1. 2. 6 Environment Monitor 

This function provides continuous monitoring and data acquisition on .the Space 
Station environment both Internal and near external. It includes the 

monitoring of electromagnetic, particulate, acceleration, and any other 
environmental factor that would Impact experiment and application subsystems. 

1.1. 2. 7 Mechanical Strain 

This function provides continuous monitoring and data acquisition on the Space 
Station structural strain and alignment. It includes the maintenance of a 

current state model of the relative locations of key components. It will be 
used by attitude, docking, and sensor processing subsystems, as well as for 
control of thermal stress induced structural damage. 

1.1.3 Command Management 

This function manages the operational commands between the ground control, the 
Space Station, the subsystems, OTVS, and the outlying platforms. 

1.1. 3- 1 Establish Validity 

This function establishes the validity of the command. It checks the user's 
authority to issue the command, determines the feasibility of the command and 
the availability of the system to perform the command. 

1.1. 3*2 Scheduling 

This work planning function schedules the timeline for delivery and the 
planned execution of the commands. 

1.1.3 - 3 Transfer Command 

This function Includes the transferral of commands between the ground, the 
Space Station, and other off -station locations. 

1.1.3*^ Execute Command 

This function executes commands. 

1.1. 3. 5 Maintain Accountability 

This function provides a timeline history of the commands, their receipt by 
the appropriate systems and subsequent action. 


1.1. ^ Attitude Operations , 

this function Includes relating to predetermined orientations, holding the 
required orientation for as long as necessary, and providing precise pointing 
for the applications. 

1.1. A.1 Determine Definitive Attitude 

This function determines the definitive attitude of the Space Station and the 
outlying platforms for use by information extraction and performance 
monitoring subsystems. It may incorporate techniques such as the use of image 
control points. 

1.1. 4.2 Execute Changes 

This function determines the desired attitude and compares It to the existing 
attitude. The function then determines and initiates a change maneuver which 
will be terminated once the desired attitude is reached. The selected 
maneuver may be dependent upon optimiza*’ion strategies based upon the attitude 
change required, time, and consumable expenditure. 

1.1. 4. 3 Space Station Model 

This function provides for a current moment model of the Space Station. It 
allows for extended structures and docked vehicles that will influence the 
response to attitude change commands. 

1»1*5 Orbital Operations 

This function predicts the orbit ephemerides, the orbital maintenance 
requirement and determines the definitive orbits for the Space Station, the 
OTV, and outlying platforms. The data products of this function are used by 
the communication, rendezvous, information extraction, operational scheduling, 
performance monitoring, and other subsystems. 

1.1.5* 1 Ephemerides Prediction and Validation 

This function produces a prediction of the Space Station's orbit by 
calculating the Space Station's position as a function of time based on a 
model of the current and anticipated drag coefficients, orbital parameters, 
and energy changes. 
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1.1. 5*2 Orbital Maintenance 

This function determines the deviations of the predicted orbit from the 
observed orbit and initiates necessary commands tc achieve the desired orbit. 

1.1. 5.3 Definitive Determination 

This function determines the definitive orbit of the Space Station. It 
includes the acquisition of the required measurement data whether it be from 
GPS, TDRSS, ground stations, laser trackers, star trackers, ground control 
points or combinations of sources. 

1.1.6 Docking Maneuver 

This function provides for docking of shuttles and the OTV with the Space 
Station and outlying platforms that comprise the Space Stations system. 

1.1. 6.1 Location 

This function provides for the acquisition of position location data on 
docking vehicles. This data may be acquired using active transponders, radar, 
lasers, optical trackers, proximity sensors, tactile sensors, and combinations 
of techniques. it also includes the maintenance of a model of the docking 
components for determining predictive closures, et cetera. 

1.1. 6. 2 Assistance 

This function provides for active assistance in executing docking manuevers. 
It Includes the interface to models, the display and interaction with human 
operators for closure, the automatic generation of commands and signals, and 
overrides for certain attitude and experiment functions. 

1.2 COMMUNICATIONS 

The communications function Is provided for both the operational andi 
application needs and includes ail external communications between the space 
station and other off-statlon location, ground, OTV's, TDRSS, and other 
satellites or platforms as well as the non-data bus internal communications, 
primarily voice and video. 
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t . 2 , 1 Channel Management 

This function includes the selection^ scheduling,, monitoring^ and interface 
control of every electromagnetic communication channel Irrespective of 
transmission mediai frequency, modulation! or encoding* 

1.2. 1.1 Selection 

This function Includes the selection of the communication channel path, e.g., 
TDRSS, direct to ground, frequencies, etc., according to available option, 
priority, and optimizing strategies. Frequency selection can Include such 
considerations as atmosphere attenuation and background noise. This function 
presumably would have access to error data and other environmental condition 
data as required. 

1.2. 1.2 Scheduling 

This function Includes the planning of communication channel requirements time 
lines, the coordination of internal and external network management functions, 
and optimization based on parameters of applications priority, available 
access time, external conflicts such as blocks of reserved communication time 
on TDRSS by the military, signal acquisition and loss times, and other 
constraints. This function encompasses internal access schedules, error 
requirements, TDRSS, and other channel usage. 

1.2. 1.3 Monitoring 

This function has as its objective an optimized channel performance. Channels 
are to be monitored for both error degradation and subsystem failure. The 
function may include the generation of test messages. Other functions such as 
channel selection, the selection of channel coding options, overall system 
status monitoring, reporting, maintenance functions, and operational mode 
changes will use information from this function. 

1.2. 1. it Interface ConCroi 

This function provides access for each Space Station subsystem and application 
system to the communication subsystem. It includes the validation of access 
rights, format conversion, and protocol. 



1.2»Z Channel Support 

This function Includes the necessary antenna polntingi formatting and 
buffering required for each communication channel or subsystem. 

1.2.2. 1 Antenna Pointing 

For each directional free space communication channel, the necessary antenna 
pointing must be determined prior to signal acquisition. A timeline of the 
pointing vector must be provided for gross tracking and a closed loop tracking 
maintenance function must be provided for each steerable antenna. This 
function requires ground station coordinates and information from the 
ephemerides data base for the Space Station and each satellite with which 
communication is required. 

1.2. 2. 2 Formatting 

This function provides the necessary format translations, protocol handling, 
and channel coding for each selected channel. Some agility of channel coding 
may be required with selection to be as indicated by the channel management 
function. Channel coding includes both companding and error detection and 
correction. 

1.2. 2. 3 Suffering 

This function provides for the necessary buffering to implement the various 
protocols and to prdvid(§ J^cess functions between channels and various 
subsystems. 

1.2.3 Transmission and Receipt 

This Is the actual carrier and modulation function according to the particular 
communication channels involved. These channels include Space Station (SS) to 
ground, SS to TDRSS, SS to OTV, SS to other platforms, and SS to shuttle. SS 
to EVA could also be included. Internal, nondigital data bus communication, 
such a§ voice and video is included In other functions. 

1.3 DATA HAH JEMENT 

This function msintalns the sets of permanent and semi -permanent data for both 
operations and applications. 



1,3.1 Generics 

This function provides the generic activities of data management. 


1.3. 1.1 Acquisition 

This function interfaces both the subsystems and applications to acquire data. 

I 

f 

1.3. 1.2 Capture I 

I 

This function demodulates datai ensures that all data has been received and 1 

I 

corrects the biases caused by refraction» antenna offsetSir transponder delaysi I 

et cetera. [ 

I 

1.3. 1.3 Processing ^ 

This function includes the processing performed on the data including 
enhancements, filtering and correctio0?i. It also includes editing the data j 

for gross anomalies «nd storing the anomalous data for failure cause | 

identification analysis. Also included is cataloging the data for permanent | 

storage and creating the necessary directories to allow automated data access | 

by authorized users. 

1.3.1. A Archiving 

This function includes the long term storing of data and the necessary editing 
and preparation for long term storage. 

1 . 3 . 1 .5 Data Del ivery 

This function handles the data requests. it determines the user's access 
authority and the availability of requested data culminating in the 
transmission of and transmits the data. It also generates notification of 
data unavailability and accepts notifications of data delivery and 

nondel ivery. 

1 . 3.2 Operations 

This function involves managing the operational data to ensure equipment and 
subsystem performance. 

f 
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1.3. 2.1 Subsystem Status 

This function monitors the performance of the subsystems as reported by the 
performance analysis functions and annunciates or otherwise provides 
Information required for operations. 

1.3«2.2 Equipment Configuration Monitor and Control 

This function ensures the correct operation of the equipment. It assigns 
roles in the event of a failure or as needed to adjust the workloadi and 

notifies system operator of the failure. 

1.3 >2. 3 Command Execution and Verification 

This function executes commands received from operations control and verifies 
that the commands have been performed. 

1.3.2. 4 Computer Operations Support of all Subsystems 

This function provides support of all the subsystems by way of computer 

resources, both computational and storage. 

1 . 3.3 Crew 

This function provides data relative to the crew members to ensure health, 

operations, recreation and training> 

1 . 3 . 3.1 Health 

This function monitois and records data concerning the health of the crew. 

This data may Include such things as radiation, contamination, and zero- 

gravity effects on the crew members. 

1.3>3*2 Duty Schedules 

This function provides task scheduling for the crew members to assure specific 
duties are carried out. 

1 . 3 . 3. 3 Skills 

This function provides skill requirements to perform certain operations to the 
crew members. 
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1.3*3*4 Entertainment 

This function provides forms of entertainment for the crew. 

1.3. 3*5 Personal Recreation 

This function provides personal recreation activities for the individual crew 
members. 

1.3. 3. 6 Library Storage, Cataloging 
This function stores and catalogs data. 

1 .3.3*7 Training 

This function provides on-board training in the operation of equipment and 
subsystems. 

I 

i 

i 

1.3.^ Logistics | 

i 

This function provides data on the logistics of consumables, supplies, spares, | 

resupplies, and crew skills. I 

f 

1.3. 4.1 Consumables 

This function provides logistic data on the consumables such as fuel, 
oxidizers, gases, and other resources that are automatically consumed during 
the normal function of the subsystems. 

1.3. 4. 2 Supplies 

This function provides logistic data on supplies such as food and experiment 
expendable items that have a scheduled consumption and replacement cycle. 

1.3. 4. 3 Spare Parts 

This function provides data on the nature and quantity of the spare parts, it 
Includes those on-board the Space Station, in ready supply locations, on other 
vehicles such as shuttles, and available for cannibalization from other 
subsystems. 

1.3. 4. 4 Resupply Scheduling 

■ i 

This function monitors the supply levels and schedules the resupply of the | 

necessary resources when they reach a minimum level. i 
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1f3>^*5 Entertainment and Recreation Supplies 

This function provide^ ^entertainment and recrestionaf supplies for the crew 
members. 

1.3. 6 Crew Skills 

This function maintains a log of the skills possessed by each individual crew 
member. 

\,M CONFIGURATION MANAGEMENT 

This function is a discipline applying technical and administrative direction 
arid surveillance to: (1) identification and documentation of functional and 
physical characteristics of a configuration item; (2) control changes to those 
characteristics; and (3) record and report change processing and 
implementation status. 

1.4.1 Configuration Identification 

This function identifies and document the functional and 
characteristics of a configuration item as set forth in the current 
or conditionally approved technical documentation (specifications, 
and associated lists, et cetera). 

1.4.2 Configuration Control 
This function is the systematic evaluation, coordination, approval or 
disapproval, and implementation of all approved changes in the configuration 
of a configuration item after formal establishment of its configuration 
identification. 

1.4.3 Configuration Status Accounting 

This function performs the recording and reporting of the information that is 
needed to manage configuration effectively, including a listing of the 
approved configuration identification, the status of proposed changes to 
configuration, and the implementation status of approved changes, 

2. MISSION AND APPLICATIONS 

These functions of the Space Station data system are required to support the 
missions with applications of the Space Station. Some of them also serve to 


physical 

approved 

drawings 
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support operational functions, although their primary role is mission related 
and would otherwise have been included as a minor role for strictly 
operational consideration. These functions include mission planning and 
support, user assistance, and mission specific functions. 

2.1 MISSION PLANNING AND SUPPORT ; 

This includes all functions that are performed prior to launch or shuttle i 

I' 

release of a mission, or prior to the execution of an on-orbit Space Station 

*■ 

maneuver. It also includes mission activity scheduling, resource allocation, | 

conflict identification and resolution, and the identification of needed ! 

1 

resources prior to actual need. 

2.1.1 Schedul inq 

This function dictates the order in which tasks will be initiated. It I 

sequences the tasks and assigns the resources to the tasks. I 

5 

I 

s 

2.1.2 Support I 

This function supports the operations and applications of the Space Station 1 

and the outlying platforms. | 

2. 1.2.1 Maintain Data Bases 

This function maintains data bases of operational and mission specific data. 

2. 1.2. 1.1 Maintain Data Base of Network Data. This function manages a data 
base of information about the tracking, and communications network, including 
station characteristics and geodetics. 

2. 1.2. 1.2 Maintain Data Base of Ephemeris Data. This function maintains st. 

data base of definitive and predictive ephemeris for each spacecraft involved 
with the missions. 

2. 1.2. 1.3 Maintain Data Base of Physical and Environmental Constants. This [ 

i 

function maintains a collection of constants such as atmospheric constants, | 

gravitational constants, magnetic field constants, et cetera, for use by the | 

operational and mission specific subsystems. | 
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2. 1.2. 1.4 Maintain Data Base of Mission Specific Data. This function 
maintains a set of data that is unique to each mission. 

2. 1.2. 2 Simulation 

This function performs simulations to determine the system's ability to 
support specific activities such as launchy maneuversy operationsy and 
repairs. 

2.1.3 Command Management 

This function manages the mission and application commands between the user 
and the experiment. 

2. 1.3.1 Establish Validity and Constraint Check 

This function establishes the validity of the command. It checks the user's 
authority to issue the command and checks constraints to ensure there are no 
conflicts with other experiments. 

2. 1.3.2 Scheduling 

This work planning function schedules the timeline for delivery and the 
planned execution of the commands. 

2. 1.3. 3 Transfer Command 

This function includes command transfer between the user and the experiment. 

2. 1.3.4 Execute Command 

This function executes commands. 

2, 1.3-5 Maintain Accountability 

This function provides a timeline history of the commandsy their receipt by 
the appropriate experiment, and subsequent action. 

2. X . 4 Instrument Operations Control 

This function controls the operation of the various instruments required to 
accomplish specific missions. The instruments and the degree of data system 
integration in accomplishing this function falls into two categories. The 
first includes those Instruments and their control that serve multiple mission 
requirements. While these instruments are mission dependent, they are 
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expected to be a part of the Space Station facility and their data system 
requirements will be provided by the Space Station data system. The other 
category of instruments serves only a limited mission role. Their data system 
functions will be assumed to be provided as part of the mission experimfsnt 
package. The impact of such functions on the data system is limited to 
interfaces, storage, communications, and environment maintenance. 

2.1.5 Centralized Library Management 

This function provides accesses, cataloging and reformatting of the support 

I Ibrar ies. 

2.2 USER ASSISTANCE 

This function provides a friendly man’-to-machine interface and guidance in 

interactive operations and procedures. 

2.2.1 Library of Functions 

This function provides the users with sets of data that support the processing 
of applications. This function also provides access to these support 
1 ibrar ies. 

2. 2. 1.1 Maintain Library of Statistical Routines 

This library provides a collection of support routines that is used to 

generate statistics on the operation and performance of the system. 

2. 2. 1.2 Maintain Library of Mathematical Routines 

This library contains a collection of support routines that perform standard 
mathematical functions. 

2. 2. 1.3 Maintain Libraries of Physical Models 

This library contains a collection of physical models pertaining to 
applications and experiments on the Space Station. It will be available to 
support the principal investigators in their information analysis activities. 

2.2.1.i( Maintain Libraries of Parameters 

This function manages sets of parameters that control and sequence processing 
tasks. 
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2.2. 1.5 Maintain Libraries of Display Formats 

This function maintains formats of the various pre-defined system displays. 

2.2. 1.6 Maintain Libraries of Data Filtering Criteria. 

This function maintains data sets that establish criteria for filtering data 
for specific Information. 

2. 2. 1.7 Maintain Library of Catalogs Describing On-Line Products, Services 
and Data Bases 

This function maintains catalogs describing the products, and data bases as 
well as procedures for acquiring the described Information resulting from 
Space Station mission acquired data. 

2. 2. 1.8 Maintain a Library of On-Line Documentation 

This function provides a library of on-line reference material, guidelines, 
procedures, reports in preparation, et cetera, pertaining to the Space Station 
systems and mission subsystems. 

Computational Resources 

This function provides the capability of processing and storing application 
specific data for the user. It also provides access to several utilities and 
data bases the user may require. 

2.2.2. 1 Processing 

This function provides for the processing performed on the application 
specific data. It includes general purpose computers but may also Include 
signal processors or other high performance devices that have multiple mission 
utility. 

2. 2. 2. 2 Storing 

This function provides the capability of storing the application data. 

2.2. 2. 3 Utilities 

This function provides several utilities for the user such as data retrieval, 
pattern matching, search, translation, mathematical reductions, image 
processing, and any algorithmic process that has multiple mission utility. 
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2.2.2.^ Data Buses 

This function provides data buses to transfer information as users require. 

2.2.3 interactive Analysis 

This function provides a more friendly user Interface. It controls the users' 
interfaces by means of menus, displays, graphics, heuristic feedback, expert 
system assistance, et cetera. 

2.2A User Aids 

This function provides a ready interface between the humans and the data 
system. It includes the necessary functions for natural language processing, 
voice recognition, voice synthesis, vision, video digitizing, and programmable 
function key displays. it also includes the maintenance of the required 

training sets or personality data bases to adapt the data system to the 
individual human users. 

2.2.5 Communications Network 

This function provides user access to the support libraries and data bases by 
means of gateways to external systems. These external data bases are assumed 
to be geographically distributed. This function includes the maintenance of 
the necessary identification, indices, and protocols to provide the access. 

2.3 MISSION SPECIFIC FUNCTIONS 

These functions impact the data system differently than the previously 
discussed functions. Generally, the specific data processing will be the 
responsibility of the mission data system. Some applications will require 
large data bases which may use common storage components. The following 

taxonomy of missions is cursory and hypothetical. For each, the significant 
data system impacts are identified. 

The mission specific functions are divided into science and applications. 
Science is further categorized as Astronomy, High Energy Physics, Near 
Environment Monitoring, and Exploration. Applications are categorized as 

Materials Processing, Earth Viewing, Communications and Navigation, 

Experimental, and Power. Each of these is further subdivided. The taxonomy 



is arbitrary and Intended as a tool for defining data system conceptual 
alternatives. No claim is made for the validity or worth of the missions. 


2 . 3.1 Science Missions 

By the taxonomy applied, nee does not Include any earth viewing sensors 
except as some physical element of the earth might aid the non-earth object of 
the observation. For example, the earth limb may be used to investigate a 
stellar or solar phenomenon. 

2 . 3 . 1*1 Astronomy 

Astronomy is arbitrarily divided Into solar, planetary, and stellar. 

2. 3 . 1.1.1 Solar Astronomy. Solar astronomy includes all Investigation of the 
sun and its close environment. Imaging sensors are presumed, with sensitivity 
ranging from microwave radiometers, through Infrared and visible to X^-rays. 
Particle counters, and starlight detection behind the corona are also 
possibilities. Devices to monitor solar pressure are also included. 

The data system considerations are: 

o Constant pointing toward the sun. This would include a constraint 
on the Space Station attitude to avoid shading the instruments, 
o Data acquisition of the particle counter and radiometer are expected 
to be moderate, but could be of a long duration, 
o Data rates for visible band sensors could be substantial. Likewise 
for the higher frequency region such as X-ray. 
o Sensors will be passive and will neither interfere with nor be 

disturbed by most other missions. Presence of man will not have 
adverse consequences. 

o Temperature sensitive measurements will use cryogenic sensors. 
Heating is only likely perturbation. 

2. 3 . 1 •1.2 Planetary Astronomy. This includes both observational and physical 
interactive investigation. Observational investigations will have 

similarities with solar observations, possibly excluding particle counters. 
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The data system considerations are similar to solar considerations except with 
fewer constraints. Pointing angles will be more varied according to mission 
scheduling. Constraint of position of Space Station relative to sun, earth, 
and targets is a consideration. Distances are sufficiently close that probes 
are feasible. Probes will include planetary orbiters which then imposes 
scheduling, communications relaying, and data processing associated with many 
of the earth applications. An additional input is the control of interactive 
probes, including teleoperator and robotic devices. Provisions for processing 
returned samples, remote telemetry acquistions, planetary models, and material 
handling all impact data system functions. 

2.3. 1*1 .3 Stellar Astronomy. Stellar astronomy includes the mapping, change 
detection, and measurements of the stars. The sensors will be similar to the 
solar missions except the focusing devices, radio and optical, will have far 
field optimization. Very large baseline interferometry may be employed. Some 
large structures and remote, off-station devices are likely. 

Data system considerations are similar to solar with additional precision 
locations for interferometry and the precision pointing requirements. Some 
long term stability impacts are also expected. 

2.3.1 .2 High Energy Physics 

These science missions may involve both observation of natural phenomena and 
the generation of artificial particles. The vacuum and potential large 
distances with little field perturbations are advantageous for some 
investigations. Counters, particle sources, and accelerators may be involved. 

Data system considerations include precise control of sources and 
accelerators. Good pointing accuracies are also expected. Some long duration 
experiments may require long term stabl 1 Ity. from the data system. 

2.3* 1.3 Near Environment Monitoring 

This encompasses all close proximity monitoring, including remote probes. 
Magnetic, gravitational, particle and electromagnetic field mapping are the 
principal data sources. 


The data systern considerations are relatively modest data acquisition rates 
from any single source; however^ there may be many simultaneous sources. 
Remote control functions and physical models with extensive computational 
requirements may also be needed. 

2.3*1.^ Exploration 

These missions include both manned and unmanned sorties. They could be to 
lunar and planetary surfaces. Since they are well into the future^ no 
elaboration will be included in this list of mission specific functions. 

The principal data system impacts will be on the specific operations, 
assembly, and checkout requirements as well as supporting operations for 
remotely placed experiments such as sensors placed on the moon. 

2*3»2 Appl i cat ions 

These missions include all of the earth viewing and near earth experiments and 
operational missions. 

2 . 3 . 2 . 1 Materials Processing 

Materials processsing applications include research, experimentation, and 
production. The applications have been categorized into chemical and fluid; 
melting, solidification and vaporization; biological; and space mining. With 
a few exceptions, the early functions will involve only minor production 
activity. However, future growth may have implications on the data system 
requirements. 

2. 3 . 2. 1.1 Chemical and Fluid Processing. These applications capitalize on 
the microgravity of space. In some applications, a controlled low 
acceleration environment may be induced. Manned presence may be detrimental 
and drive the implementation toward structures that are mechanically uncoupled 
from the habitation center. Applications will include chemical reactions and 
polymerization, fluid convection, phase transition, surface, and bubble 
phenomena. Initially, applications will be experimental with some potential 
pilot production processes expected. Commercialization will be some years 
Into the future. 
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Datd isystem considerations will Involve controls, Including closed loop 
servomechanisms, and possibly some fall operational functions to prevent the 
loss of considerable investment in long duration experiments through short 
duration interruptions. As pilot projects and later commercial projects 
evolve, the logistics management of raw materials and finished products must 
be accommodated. Data rates will be minimal except for isolated experiments 
involving imagery. Even they will be small compared with the earth viewing 
image sensors. Physical separation of facilities from the habitation center 
may require free space or other communication channels such as fiber optics. 

2. 3. 2. 1.2 Melting, Solidification, and Vaporization. These applications 
Include crystal growth, ultra-purification, preparation of glasses and 
amorphous solids, vapor deposition, solidification, preparation of ceramic 
material processes^ and the determination of chemical and physical material 
properties. The mlcrogravity environment makes container less processing and 
its accompanying lack of side wall contamination feasible. Not all these 
applications will be as susceptible to minor acceleration perturbations. Some 
may be suitable for accommodation on the habitation center. Pilot production 
systems are possible within the initial time frame of interest with 
potentially some commercial applications. Large commercial applications that 
would exceed the physical accommodations of the habitation module are not 
likely within the early time frame. 

Data system considerations are expected to be minimal. They will be similar 
to other materials processing applications. 

2. 3.2. 1.3 Biological Processing. These applications include both the 
preparation of biological materials and biological separations for scientific 
purposes. Most will involve the eventual removal of the resultant material. 
Pilot systems and possibly some commercial production systems will be 
operational during the early time phase. Small perturbations of the zero 
acceleration environment are not likely to be a problem. 

Data system considerations are expected to be minimal. They will be similar 
to other materials processing applications. 
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2,}.2,],k Space Mining. Space mining may Involve sorties; to discrete objects 
such as the asteroids or svyeeping operations. They will Involve Uirgt scale 
operations that are not likely in the early time period. Early time period 
may involve some experimental missions. 

Data system considerations will be for specific assembly and checkout systems 
to support the space operations. Initial processing of the gathered material 
Will likely be incorporated Into other materials processing applications. 

2. 3 . 2. 2 Earth Viewing Applications 

All earth viewing applications have the point in common that the resultant 
product is data. Consequently, they will be drivers for the majority of the 
data system considerations. They also are high potential candidates for 
inclusion of the function in subsystems of the Space Station system 
facilities. A distinction is made, somewhat arbitrary for this study, between 
operational earth viewing applications and experimental. All those 
applications In this paragraph are considered operational for data system 
considerations. The distinction for data system purposes is the operation 
applications are expected to have well-defined requirements in terms of data 
acquisition periodicity, targets, freshness criteria, and processing. Total 
data quantities are also likely to be greater than for experimental 
applications. They are categorized further as: Earth Resources Detection and 
Monitoring, Earth Dynamics Monitoring and Forecasting^ Ocean Condition 
Monitoring and Forecasting, Environmental Quality Monitoring, Weather 
Observation and Forecasting, and Climate Research. 

2. 3 . 2. 2.1 Earth Resources Detection and Monitoring. These applications 
include the detection and mensuration of non-reusable resources such as 
minerals and hydrocarbons and the monitoring of renewable resources such as 
water> flora, and In some instances fauna, There will be interaction with 
other applications data such as weather, climate, and environmental quality. 
These have been categorized as: agriculture; forestry; rangeland; hydrology 
and limnology; geology; geography, demography, and cartography; and coastal 
zone applications. 
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2.3*2*2J.1 Agriculture Applications. These applications include the 
identification, mensuration, and assessment of agricultural products. 
Implicit In assessment is the detection of anomolous conditions such as 
insect, weather, or human-induced stress. future operational systems will 
merge image and discrete data acquired with multiple sensors in multitemporal 
observations with collateral data bases. The Information content of the 
remotely sensed data will be dependent upon the primary sensors used, the time 
of the observation, and the environmental conditions, particularly atmosphere 
and sun angle, when the data was acquired. Operational applications are 
presently accomplished with free flyers. In the time frame of interest, 
additional sophistication may be expected. The principal evolution may be 
expected to be toward a greater variety of spectral bands and Increasing 
collateral data bases. 

Data systems considerations Include largs bandwidth communications and data 
processing requirements as well as data base management impacts. Some near 
real time uplink control paths and associated command management will also be 
required. 


2. 3.2. 2. 1.2 Forestry Applications. These applications have similarities to 
the agriculture applications. The major difference is the longer cycle of 
variations which will generally require less frequent data updates. However, 
stress detection may be equally demanding. Additional applications are fire 
detection and fire fighting information. 

Data system considerations are comparable to those of agriculture. The 
collateral data storage and manipulation requirements may be less. Some real 
time uplink control may be required. 

2. 3*2. 2. 1.3 Rangeland Applications. These applications have similarities to 
the agricultural applications. There may be some high resolution monitoring 
of selected regions for stock count and errosion. 

Data system considerations are similar to forestry applications. 
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2.3>2>2.l.l« Hydrology and Limnology Applications. Hydrology applications 
include the monitoring of surface and subsurface watery either directly or 
indirectly^ and the maintenance of models of water tables and flows. These 
applications require Interfaces wtlh geographic and topographic data, Ice 
data, and weather data. Uses include drainage and water resource management, 
flood control environmental I impact studies, percolation prediction, and so on. 
Direct jmeasurements would Involve the Identification and mensuration of water 
bodies, subsurface water detection using microwave sensors, and telemetered In 
situ data. Indirect monitoring would measure other phenomena as surrogate 
indicators. An example might be vegetation stress. 

Limnology is the study of rivers and their Interface with the ocean bodies. 
Applications and data requirements are similar to hydrology. Some limitations 
may be expected to result from low inclination orbits since some necessary 
data must be acquired from the polar region for both hydrology and Umnology. 

Data system considerations are comparable to other earth resources monitoring 
applications. 

2 . 3 . 2. 2. 1.5 Geology. Geology applications include the detection and mapping 
of earth crustal material. In addition to the sensor data needed for 
rangeland applications, other ss^nsory data Indicative of subsurface 
information is required. thl,% include? jjiicfSiWave, thermal inertia, and 
magnetic maps. The spatial resolution for visible and near infrared images 
are likely to be greater than for renewable resource monitoring. The period 
between observations is longer. Overall data volumes are expected to be less. 

Data system considerations are similar to other earth resources detection and 
monitoring applications. Unique data bases are required with the associated 
storage and management implications. 

2.3.2.2.1.6 Geography, Demography, and Cartography. These applications can 
tolerate long periods between observations but require greater spatial 
resolution. Multiple observations to detect seasonal variations are 
potentially useful but updates on the order of years are reasonable. Low 
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Inclination orbits will restrict the application to less than full global 
coverage. 

Data system considerations Involve the need for precision spatial resolution 
and registration as well as storage and management of extensive collateral 
data sets. 


2. 3.2*2. 1.7 Coastal Zone Monitoring. These applications combine elements of 
agriculture, limnology, and other earth resources applications with ocean 
monitoring In the limited region of coastal zones. The major difference Is In 
the collateral data sets. 

Data system considerations are similar to other earth resources applications. 

2. 3 . 2. 2. 2 Earth Dynamics Monitoring and Forecasting. These applications 
Include tectonics, geodynamlcs, geology, and geomagnetics. They are 
characterized by needs for high spatial resolution and precision registration 
of Images acquired over long periods of time, possibly measured In years. 
Sensors will generally be comparable to those used for other earth viewing 
applications with the addition of some of the field mapping sensors similar to 
those used for geology. 

2. 3 . 2. 2. 2.1 Tectonics Applications. This application Involves the precise 
measurement of the location, extent, and movement of the plate structure In 
the earth shell. Precise simultaneous measurement from space Is advantageous*. 
Laser ranging and very long baseline Interferometry are two techniques. 

Data system considerations Include the need for precision location of the 
Space Station. The data rate and volume impacts will be low. 

2. 3 . 2. 2. 2. 2 Geodynamlcs Applications. These applications Include detecting 
and monitoring changes In the earth's physical structure. It includes 
ephemeral phenomena such as vulcanism and earthquake detection. The sensors 
will be similar to those needed for geology and other earth dynamics 
app I i cations. 


Data system considerations, In addition to those common to other earth 
dynamics applications, are driven by the need to detect and monitor ephemeral 
events. This may require real time uplink or onboard Interactions and command 
management. Some real time scheduling and work planning functions are 
Involved. 


2. 3*2.2. 2. 3 Geodesy. This application Involves precision measurement of the 
earth. The basic sensor Is a precise rader a!tlm:!!?ter<> 

The major data system considerations are the need to know precisely the 
position of the sensor platform. This may require extensive orbital model 
processing. The major driver Is the need to determine the average height of 
the ocean when the measured surface Is fluctuating due to wave, surface 
Irregularity, and tidal phenomena. The relative measurement Is against a 
platform that has positional ambiguity. Data rates and quantities are low. 

2. 3. 2. 2. 2.^ Geomagnet Ics. This application Involves the measurement and 
mapping of the magnetic structure of the earth. The principal sensors are 
magnetometers. Application will be restricted by low Inclination orbits. 

Data system considerations are primarily to avoid contaminating the 
measurements by the structure supporting the sensors. A tethered probe Is one 
Way to minimize such effects. 

2. 3*2. 2. 3 Ocean Condition Monitoring and Forecasting. These applications 
Involve the monitoring and interpretation of phenomena In the seas, at the 
alr/sea boundary and In the low atmosphere near the sea surface. Currently, 
the microwave region Is the most successful. Instruments Include passive 
radiometers and active microwave sensors such as radars and scaterometers. 
Currently, the highest resolution Is obtainable using synthetic apei'ture radar 
(SAR). Information Is also obtained In the visible range, particularly as It 
applies to biological content such as plankton formation. Models and data 
bases are maintained and executed to forecast the various conditions. 
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2. 3. 2. 2. 3.1 Physical Oceanography Applications. These applications are 
concerned with such ocean parameters as temperature, wave height, sea state, 
currents, salinity, and plankton locations. 

The major data system considerations Involve the high data rates and volumes 
and the high bandwidth processing required for processing the SAR data. The 
active microwave sensors also consume large quantities of power. Other 
present problems Include the difficulty of registering microwave Images from 
different spectral bands when the targets are oceans with changing but not 
distinct surface features. 

2. 3*2.2. 3*2 Sea Ice. These applications Involve the monitoring of the 
location of sea Ice and properties of the Ice. These properties include 
thickness, salinity, temperature, and age. Age Is often inferred from 
salinity at present. For navigational purposes, the maintenance of an Iceberg 
map would be useful. Interrogation of the data base by remote user systems 
could be included In the scenario. In addition to tracking by remote sensing 
from space. In situ transponders seeded by aircraft could be employed. 

Data system considerations are similar to physical oceanography with the 
addition of Interrogation access functions. 

2. 3. 2. 2. 3. 3 Surface Atmosphere. The Interface between the sea surface and 
the atmosphere Is a complex physical relationship. Surface phenomena are 
Indicators of wind speed and direction. Scaterometers, especially polarized 
signals, are also Msed. Atmospheric measurements at or near the sea surface 
provide Indications of water vapor content. 

Data system considerations are similar to physical oceanography. Powerful 
computational resources are required to ascertain the correct surface 
atmosphere models. The Information must be extracted from a complex of 
multiband sensor Information. Essentially, the surface data must be processed 
such that the noise from the near surface atmospheric distortion Is backed out 
of the signal complex and the primary signal is discarded. 



2. 3. 2. 2.4 Environmental Quality Monitoring* These applications Include air, 
water, and land pollution. 

2. 3*2. 2, 4.1 Air Quality Monitoring. This appllca'ilon concerns the monitoring 
of the alt for constituents such as chemicals and dust particles. Data 
sources Include the noise due to atmospheric scattering that can be determined 
from the various mul tl spectral sensors, especially in the microwave regions, 
atmospheric sounders,, laser Instruments such as UIDAR, and limb sounders. 

Data system considerations are similar to those for physical oceanography with 
additional Instruments. 

As models with greater resolution are constructed, the data storage and access 
Impact will become significant. The vertical dimensions approach 100 miles. 
This has the potential to become very large for a global coverage model. 

2.3.2. 2.4.2 Water Quality Monitoring. This application concerns the 
detection of pollutants In water. Many of the data sources and sensors will 
be similar to the earth resources applications, particularly hydrology and 
limnology. Some LIDAR sensors are also being considered. 

Data system considerations are similar to hydrology and limnology. 

2. 3.2. 2. 4. 3 Land Quality Monitoring. This application Is a special subset of 
some of the earth resources monitoring applications. Visible band sensors 
will be a primary information source. There will likely be some near real 
time human Interaction involving pointing of high spatial resolution sensors. 

Data system consideration will be comparable to rangeland and coastal zone 
monitoring applications with possible added functions of work planning, 
scheduling, and command management. 

2.3. 2. 2. 5 Weather Observation and Forecasting. These applications involve 
data acquisition on a global scale from high and low atmospheric and sea 
surface targets as well as some solar measurements. Generally, an Integration 
with other satellite and ground based data acquisitions can be expected. The 
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users may be both Institutional (e.g., National Weather Service) and 
Individual organizations. The sensors Include particle counters, scanning 
radiometers, sounders, and associated ocean monitoring sensors. The 
applications have been classified Into: Nowcasting, Short Range Forecasting, 
Long Range Forecasting, Mesoscale Meteorology, and Agriculture Meteorology, 

2. 3. 2. 2. 5*1 Nowcasting Applications. Nowcasting Involves the determination 
of present or within the last hour weather conditions. It Includes the 
detection and tracking of severe storms, agricultural freeze conditions, and 
Icing or road hazards such as fog. It Is characterized by the need for 
current, detailed, but localized information. Polntable sensors may be 
expected. 

Data system considerations Include the need to manage. Including all the 
Included acquisition and processing steps, the various Imaging and sounder 
sensor data. In addition, there are the needs to manage commands and to 
process data with a critical timeliness requirement. Maximum throughput 
delays on the order of fifteen minutes from command to delivery of Information 
to the user may be expected. 

2,3. 2. 2. 5. 2 Short Range Forecasting. This application involves world-wide 
models that are computationally Intensive and require data from a multitude of 
sources. Currently, the models execute every four hours. In the time frame 
of interest, one or two hour updates may be expected. The forecast is for 
near time weather conditions of now to three days In the future. Inputs to 
the models Include solar insolation, earth radiation, sea state, temperature, 
winds, and atmospheric temperatures and pressure at several layers. The 
current significant feature is the need to deliver answers from the models on 
an operational schedule with or without updated data input. An innovative 
system in the time frame of Interest could be based on a more Interactive 
process whereby input data is acquired as needed by the models rather than as 
a scheduled pipeline process. 

Data system considerations are the need to manage the data from the various 
sensors and to deliver it operationally. Availability of the data management 
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resources will be Important. Some Interaction and access to remote data bases 
are also considerations. 

2. 3.2. 2. 5. 3 Long Range Forecasting. These applications are similar to those 
short range forecasting except they Involve more parameters, particularly 
the effects of solar and earth radiation and ocean/atmosphere interaction. 
The models are structured differently, but the data inputs are similar. 

Data system considerations are similar to short range forecasting. 

2. 3. 2. 2. 5.^ Mesoscale Meteorology. These applications are similar to short 
and long range forecasting except the geographic areas of interest are more 
restrictive, usually regions around population centers, and data Is acquired 
on a higher spatial resolution but often smaller areal coverage. They may 

also exhibit closed loop user control. The models usually Include more 
provisions for local effects. 

Data system considerations are similar to the forecasting applications with 
the need for management of user commands. 

2. 3.2. 2. 5. 5 Agriculture Meteorology. These applications are a combination of 
short range forecasting, mesoscale meteorology, nowcasting, hydrology, and 
earth resources monitoring. Temperature, solar insolation on the earth 
surface (not atmosphere), and ground moisture are determined. Sensors are 
similar to those used In the above named application. Coverage Is targeted to 
areas of agricultural Interest. This may vary with seasons and stress 
conditions. Some user Initiated data acquisition may be expected. 

Data system considerations are similar to sea Ice monitoring. 

2. 3*2. 2. 6 Climate Research. These applications Involve the acquisition and 
management of synoptic data on a global scale. The information sources are 
similar to other applications, particularly In the weather observation and the 
earth resources areas. Some of the downstream processes differ. Climate 

research applications are classified into; global biomass monitoring, ice and 
snow pack, atmospheric constituents, global surface water, and energy budget. 
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2. 3*2. 2. 6.1 Global Bjomass Monitoring. These applications have a great deal 
of commonality with agricultural, forestry and rangeland data acquisition 
needs. The timing of the observations are not as critical but the extent of 
targets must be throughout the global land mass. 

Data system considerations are comparable to the indicated earth resources 
monitoring applications. 

2. 3.2. 2. 6. 2 Ice and Snow Pack. These applications Involve the mensuration 
both spatially and qualitatively of the Ice and snow In the world. The 
extent, water content, and other properties are Inventoried. Many functions 
common to sea ice monitoring are required. Sltr.llar sensors and processing Is 
required. Timeliness and update periods are not stringent. Low inclination 
orbits will severely restrict the necessary data acquisition. 

Data system considerations are comparable to that subset of the weather 
observation applications. 

2. 3.2.2. 6. 3 Atmospheric Constituents. Tfiose applications involve the 
detection, quantification, and cataloging of atmospheric constituents. There 
Is commonality with air quality monitoring and some of the weather observation 
functions. Additional sensors and special processing will be involved. 
Timeliness and observation periodicity are not as stringent. 

Data system implications are comparable to those similar applications 
Identified above. 

2. 3. 2. 2.6.^ Global Surface Water. These applications involve the detection 
and mensuration of water on a global scale. The sensors, processing, and 
functions are similar to those required for hydrology, except on a global 
scale. Timeliness and observation periodicity are not stringent, although 
there are certain constraints to obtain synoptic data. 

Data system considerations are comparable to those for hydrology. The total 
information handling requirement for any given synoptic coverage will be 
larger. 


2.3>2.2.6.5 Energy Budget. These applications Involve the monitoring and 
cataloging of the earth energy budget In all spectral regions. It Is 
comparable to the similar subset of the weather observation application. 
Sensors are predominantly radiometers and solar particle counters. Some will 
be solar directed. 

Data system considerations are comparable to mesoscale meteorology and 
nowcasting. 

2f3.2.3. Communication and Navigation 

These applications include: voice and data relay, In situ telemetry data 
acquisition^ control, surface navigation^ and surface and near earth tracking. 
Intentionally, land-based poInt-to-poInt communications as currently being 
performed with geosynchronous satellites are excluded from these potential 
mission specific functions of the Space Station. 

2. 3.2. 3.1 Voice and Data Relay Applications. This application Includes the 
communications required to support the other applications. Communications 
could Include those with a remote logical connection. For Instance, the 
experimental facility might have need for some data transfers or voice 
communications that might use other satellite links but because of the need to 
support specific experiments, the channels would be established anyway. Under 
those conditions, the facilities of the Space Station could provide the 
relaying applications. This is distinct from the communications functions 
identified in the list of operational functions. 

Data system considerations are comparable to those for operational 
communications. The only Impact would be an Increase in the channel capacity 
requirements. 

2. 3 . 2. 3 . 2 In Situ Telemetry Data Acquisition. These applications would 
involve the command and receipt of data acquisition from other space platforms 
and earth or sea-based platforms. Some logical association with other 
applications is assumed. 


Data system considerations are generally the need for telemetry command and 
data acquisition from Inexpensive commendation devices. Frequencies and 
bandwidth requirements will be low. The need to maintain a data base of 
transceivers, formats, locations, and access protocol must be considered. 

2. 3. 2. 3.3 Control Applications. Some applications In remote locations may 
require control from the Space Station. Discrete signals will not have much 
bandwidth requirements. Some applications, such as those Involving 
teleoperator may require greater bandwidth. Some control applications may 
Involve closed loop feedback such as video Imagery. 

Data system considerations are comparable with the operational communications 
requirements. These applications will increase the system sizing 
requirements. 

2. 3. 2. 3.^ Surface Navigation. These applications Involve navigation aids to 
surface vehicles. Ranging devices and tracking models would be required. 

Data system considerations are the need to provide for user Interrogation, 
direct broadcast to users, and the need for precise Space Station location. 

2. 3. 2. 3. 5 Surface and Near Earth Tracking. These applications will Involve 
transponders and maintenance of location models. Active sensors such as radar 
and visible imagery may also be Involved. Ship tracking and aircraft control 
are possibl 1 ities. 

Data system considerations are a function of the extent of implementation. 
The need to passively detect and track ships and aircraft would have a major 
Impact. An integration of Space Station capability with ground based systems 
Is a possibility. Any Implementation in the near term of interest will likely 
be on a pilot project basis. Antenna systems with broad coverage would be 
required. 

2. 3. 2. 4 Experimental Application 

These applications will span the materials processing, earth viewing and 
communications and navigation applications. The distinction in their being 
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experimental Is there will be less stringent timeliness requirements, the 
extent of coverage and consequent data volumes will be restricted, and the 
processes will be less defined. These areas will also most likely be 
encountered In the near time period Interest. There will likely be a need 
for frequent changes In processing and direct human Interaction. 

Data system considerations Include the need to provide for any or all of the 
functions previously described In the application areas. In addition, there 
will be the need for direct operator Involvement and frequent change In 
processing. Flexible data system support Including software, development 
support will be required, 

2. 3.2. 5 Power Applications 

These applications Include the acquisition of energy and the generation of 
power for use external to the Space Station. Any near term applications are 
expected to be In the nature of a pilot system. Eventually, separate 
structures and platforms may evolve. The type of the energy acquisition may 
be Solar, space mining, or nuclear. Methods of packaging and transporting the 
energy must evolve. The nearest term considerations involve microwave 
transporting to earth's surface. 

Data system considerations will Involve complex pointing and control systems 
as well as the space operations associated with full scale commercial 
materials processing. 
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MINUTES OF SPACE STATION BLUE RIBBON PANEL MEETING 

JUNE 30 , 1982 


MINUTES OF SPACE STATION BLUE RIBBON PANEL MEETING 

JUNE 30 , 1982 


1. INTRODUCTION 

A Blue Ribbon Panel cotnprlolng both NASA and General Electric personnel with 
background and experience applicable to the Space Station Data System met June 
30 , 1982 . This meeting was convened under contract to NASA Goddard Space 
Flight Center NAS5-2719^» The express purpose was: 

"To focus the study on key Issues of Space Station Data Systems with 
an emphasis on technoiogy that has a high potential for reducing 
1 ife cycle cost." 

The meeting was held at the General Electric AFO Conference Room, Room 727, 
777 l^th Street, Washington, O.C. 

1 . 1 ATTENDEES 

A list of the participants of the meeting Is provided In Table 1. 

1.2 AGENDA 

Bruce Lees, Manager Communication and Space Systems Programs, Aerospace Field 
Operations, hosted the meeting. The meeting, under the moderation of Tom 
Thompson, adhered to the agenda of Table 2. The meeting was structured to 
Identify significant data system Issues by approaching them first In a 
straightforward manner, then via pr)tentiai applications, and finally from a 
technology viewpoint. 

Some specific goals for the meeting are listed in Table 3* 

1.3 BACKGROUND 

Jim Neiers presented a background on the study along with the Initial 
guidelines and assumptions. Copies of those charts Identifying the project, 
study guidelines, some strawman objectives for the Space Station and some 
additional assumptions are Included as Figures 1 through 1*, respectively. 




Table 1. Attendees 


Name 

Oreanization/Locat Ion 

Phone 

Tom Thompson 

GE/Huntsvl 1 le 

205-837-7701 (Ex, 

Carl Mosley 

ge/vf 

215-962-i*C9A 

Frank Lynch 

6E/CR6D 

518-385-^171 

Lfnwood Jones 

GE/VF 

21 5-962-3008 

Lee Holcomb 

NASA/HQ 

202-755-2361J 

Jim Nelers 

GE/HuntsvMle 

205-837-7701 (Ex. 33) 

John Anderson 

NASA/HQ 

202-755-2^13 

|Ed Chevers 

NASA/ JSC 

713-^83-2851 

Harry Benz 

NASA/Ha 

202-755-3273 

Howard Kralman 

GE/VF 

215-962=^674 

Arch P^i?rk 

GE/Lanham 

201-459-2900 (Ex. 456) 

C. Axtell 

GE/SUnnyvale, CA 

408-734-4980 (Ex, 429) 

John C. Conrad 

GE/VF 

215-962-4967 

Richard W. Heckelman 

GE/IC Sys. Lab| Syracuse 

315-456-3067 

Hank Graf 

GE/HuntsvI 1 le 

205-837-7701 (Ex. 32) 

Sheryl Golden 

GE/Huntsvi 1 le 

205-837-7701 (Ex. 50) 

Ted Connell 

NASA/GSFC 

301-344-7992 
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Table 2. Agenda 



8:00 

Assemble 

8:30 

Introduct Ion 
- Agenda 

8:^0 

Overview of Program 

- Purpose 

- Ground Rules of Study 

- Strawman Definition 

9:00 

Issues 

- identification 

- Discussion 

10:15 

Break 

10:30 

Applications Influencing Data System Requirements 

- Uses 

> Data System Requirement 

- More Issues 

12:00 

Break 

12:l»5 

Technology 
- Data System Impact 
“ More Issues 

2:00 

Technology Needs 

3:00 

Break 

3:15 

Review 

- Summary 

- Study Direction 

it:00 

Adjourn 
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Table 3* Specific Goals of Meeting 

1. IDENTIFY DATA SYSTEM ISSUES FOR FURTHER STUDY 

PRIORITIZE BY POTENTIAL PAYOFF 

2. PROVIDE GUIDANCE FOR STUDY 

IDENTIFY INFORMATION SOURCES 
IDENTIFY APPROACHES 

ACQUAINT STUDY TEAM WITH OVERVIEW OF ISSUES 


REDUCE PRECONCEIVED BIASES ON ISSUES 






eight month study that will produce reports recommending implementation alternatives and data 

SYSTEM TECHNOLOGY DEVELOPMENT PROJECTS BASED ON TECHNICAL ANALYSES OF SPACE STATION OBJECTIVES, 
"NEEDS*' CONCEPTS, USER REOU! REMENTS , OPERATIONAL ENVIRONMENT AND EMERGING TECHNOLOGY. 



USER COHHUHITY 





STUDY WILL BE RESTRICTED TO THE DATA SYSTEM COMPONENT OF THE SPACE STATION. 



Figure 2. Study Guidelines 




OBJECTIVE / SUBOBJECTIVE 

PROVIDE FOR MANNED PRESENCE 

o MAINTAIN HABITABLE ENVIRONMENT 

o ACHIEVE ULTRA RELIABILITY FOR LIFE DEPENDENT FUNCTIONS 

* t . 

ACHIEVE ECONOMICS OF MULTIMISSIONS 

o SUPPORT MULTIPLE CONCURRENT EXPERIMENTS AND APPLICATIONS 
o PROVIDE FOR COMMON FUNCTIONS 
o EXPERIENCE USER ACCEPTANCE 

SUSTAIN AN INDEFINITE LIFETIME 

p BE EXPANDABLE TO SUPPORT MULTIPLE STATIONS IN BOTH GEOSYNCHRONOUS 
AND LOW EARTH ORBITS 

•o BE FLEXIBLE TO SUPPORT CONFIGURATIONS WITH CHANGING SENSOR MIXES 
o EXHIBIT TECHNOLOGICAL TRANSPARENCY TO SUPPORT FUTURE EXPERIMENTS 


BE ECONOMICALLY JUSTIFIABLE 

o BE IHPLEMENTABLE IN A PHASED SEQUENCE TO MINIMIZE UNPRODUCTIVE INVESTMENT 
o REDUCE MANPOWER LEVEL REQUIRED FOR SUSTAINED OPERATIONS 


SUPPORTING SUBOBJECTIVES 

0 PROVIDE EXPERIMENT ENVIRONMENT 

o PROVIDE SENSOR DATA PROCESSING 

' o PROVIDE STATION OPERATIONS 

o PROVIDE DATA MANAGEMENT 

o SUPPORT USER/EXPERIMENT 

o PROVIDE FOR MULTIPLE MODES OF DATA 

INTERACTIONS 

DISTRIBUTION 

o SUPPORT DATA ACQUISITION 

o PROVIDE FOR USER DATA REQUESTS 

o PROVIDE AUTOMATIC COMMAND 

o BE COMPATIBLE WITH NEEDS DATA 

GENERATION 

ARCHIVE CONCEPTS 

o MEET NEEDS TIMELINESS CRITERIA FOR 

o APPROACH OPERATIONAL AVAILABILITY 

DELIVERY OF PROCESSED DATA TO USER 

OF 0.99 


o ACHIEVE 0.9999 AVAILABILITY FOR 

• 

CRITICAL FUNCTIONS 


Figure 3* Strawman Station Objectives for Purpose of Study 
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Figure 4. Assumptions for Purpose of Study 





2. OVERVIEW 


During the course of the meeting, three charts were developed. 

a. Data system Issues. 

b. Applications with expected data system Impact. 

c. Technologies with data system Impact. 

Each Item on the chart was then reviewed and assessed as to the relative 
Importance or emphasis that should be given to that topic during the remainder 
of the study. Each Item on the technology chart was ranked high (h), medium 
(m), or low (1) as to need for emphasis for the Space Station. The assumption 
was that the Item was on the list because It was going to Impact the Space 
Station data system. Therefore, It was a question of progress without 
specific additional involvement. If other agencies or commercial needs were 
driving the development, that Item received a low ranking. Those needing 
specific attention were rated high. 

It was recognized that this was a "quick and dirty" and premature attempt 
since the data system requirements had to be developed first. This list will 
serve as a check list later in the study. 

Next, the data system issues were rated high, medium, and low as to a weighted 
judgment of impact and Importance. This was the major output of the meeting. 
The resultant list will serve as guidance as to where our attention will be 
focused during the remainder of the study. These lists of Issues, 
applications, and technologies with potential Impact on the Space Station 
system are Included as Tables k through 6, respectively. 

3. DETAILED NOTES 

The following notes apply to the detail discussions that transpired during the 
meeting. They are generally chronological except when it was obvious that 
some rearranging would benefit understanding. 

3.1 SCENARIO TO BOUND EXPERIMENTS 

An upper limit on the number of experiments that can be handled in parallel on 
a Space Station is a desirable constraint when considering data system 
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Table h. Issues 


H 

PARTITION OPERATIONS (HOUSEKEEPING) VS. MISSION (APPLICATIONS) 

H 

AUTONOMY - CONTROL/MISSION/OPERATIONS 

LIFE CYCLE COST 
NATIONAL RESOURCE 
TIME PERIOD 
ON-BOARD SCHEDULING 

M 

SURVIVABILITY 

H 

ARCHITECTURE 


STANDARDIZATION 

AVAILABILITY 

DATA SYSTEM END-TO-END COMPATIBILITY 

H. 

AUTOMATIC FAULT DETECT ION/ ISOLATION/RECONFIGURATION 

H 

ACCELERATE AVAILABILITY OF SPACE QUALIFIED HIGH TECHNOLOGY HARDWARE 


COMMERCIAL HARDWARE 

H 

LOGISTICS 

H 

DATA BASES - LOCATION/SIZE 

H 

CREW MAKEUP/REQUIREMENTS 


MAN/MACHINE INTERFACE 
ROLE OF MAN 
EXPERT SYSTEMS 

H 

ROLE OF GROUND DATA SEGMENT 

D 

ROBOTICS 

M 

SECURITY 

H 

AUTOMATION OF SUBSYSTEM 

H 

FLEXIBILITY/GROWTH 

M 

COMMUNICATIONS 

H 

POSITION AND ATTITUDE ' 


H - High impact or importance to the data system 
M - .Medium impact or importance to the data system 
L - Low impact or importance to the data system 


If 

>« 

\l 
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Table 5. Applications 




FEATURES LONG DURATION CAPABILITY 

LARGE STRUCTURE | 
ON STATION REPAIR/REFURBISH/RECONFIGURE f 
MANNED PRESENCE j 


B 

LIFE SCIENCES 

D 

MATERIALS PROCESSING - ROBOTICS 

H 

ASTRONOMY 

H 

SATELL 1 TE REFURB 1 SH/REPA 1 R/SERV I CE/CAL 1 BRATE 

n 

SPACE CONSTRUCTION 

H 

SATELLITE COMMAND 6 CONTROL & DATA MONITORING 

H 

COMMUNICATION RELAY 

H 

EARTH OBSERVATION - EQUATOR lAL/POLAR 

H 

MANEUVERABILITY - COLLISION AVOIDANCE 

H 

MANNED ORBITAL TRANSFER 

M 

DEBRIS TRACKING 

M 

CLOSE ENVIRONMENT MONITOR (INTERNAL 6 EXTERNAL) 

H 

OPERATIONS PROCESSING (INFORMATION EXTRACTION) 

B 

WEAPONS SYSTEM RESEARCH 

B 

VLBI 

B 

HIGH RESOLUTION RADAR 

H 

VIRTUAL SENSORS 

B 

MANUFACTURING 

B 

ZERO-GRAVITY RESEARCH 

M 

PROPULSION RESEARCH 


H - High impact or importance to the data system 
M - Medium impact or importance to the data system 
L - Low Impact or importance to the data system 

! 

h 

ij 

t: 
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Table 6. Technologies 


COMMUNICATIONS 

L LASER LINKS 

L FIBER OPTICS (COUPLERS) 

M COMPRESSION 

M CODES - REDUNDANCY 

H STEERABLE ANTENNAS/ELECTRONIC 

H MULTIPLEX 

H TRANSMITTERS 

DATA STORAGE 

M DATA BASE ARCHITECTURE/SYSTEMS 

M NON VOLATILE MEMORY 

H RADIATION HARDNESS 

L VIDEO DISC/BUBBLE 

H UPLINK DB UPDATF./QUERY 

H ARCHIVING (MORE DENSE) 

PROCESSING 

I nleTDlDnTcn ^ oadaiici 

b u i u I i\ I I bU or r 

L HARDWARE 

L MICRO 

H CONTROL CENTRALIZED OR DISTRIBUTED 

H MAN/MACHINE INTERFACE 

AUDIBLE 

DAMAGE ASSESSMENT 

DISPLAYS - VISUAL INPUT/OUTPUT 

L ARTIFICIAL INTELLIGENCE 

NATURAL LANGUAGE PROCESSING 
INDUCTIVE REASONING 
INFERENTIAL REASONING 
HEURISTIC ANALYSIS 

SOFTWARE 

H STATION OPERATING SYSTEM 

H DEVELOPMENT METHODOLOGY 

L METRICS 

H ARCHITECTURE 

L ROBOTICS 

H SPACES STATION SUBSYSTEM AUTOMATION 

H FAULT TOLERANCE 

H SUBSYSTEM S EXPERIENCE INTERFACE STANDARDIZATION 


H - High impact or importance to the data system 
M - Medium impact or importance to the data system 
L - Low impact or importance to the data system 
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alternatives. The discussion to establish this limit was postponed and not 
resumed later as planned. 

3.2 ACCOMMODATION OF MILITARY MISSIONS 

There was considerable discussion throughout the meeting as to factors and 
sub Issues Involving military missions. There should be some allowances for 
Inclusion of military missions, even In the low Inclination orbit. We cannot 
Ignore the military applications, but there Is a question as to the degree we 
should complicate the data system requirements. Subsequent discussions 
provided some guidelines as to reasonable boundaries. For Instance, defense 
from overt attacks will not be considered as a legitimate data system 
function* Special security and encryption will be provided by the user and 
only bandwidth Implications would be considered. However, the summary 
statement Is "As long as the Space Station Is a national resource. It Is safe 
to say that military applications will exist." 

3.3 FUNCTIONS OF EARLIER CONCEPTS 

Howard Kralman presented some material from a study performed for a Space 
Station concept, subcontracted to Rockwell 12 years ago. While the technology 
has changed, many of the functions are still valid. In this study, functions 
were split Into those In support of the applications and those of a 
housekeeping nature. An Interesting concept Included station controllers' 
consoles and a captain's station. This Is probably still valid. 

In this study. Information Management System (IMS) was analogous to the data 
system In the current study. Two charts from Howard's presentation are 
Included as Figures 5 and 6. These charts list on-board functions and ground 
functions. 

3. A SECURITY 

Some security needs were discussed. How do we handle the problem of keeping 
data separate for joint military and commercial missions, or even between 
commercial users? Also, the problem of keeping data away from outside 
Intruders exists. Each group will want to protect Its own data. 
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Figure 6. Ground IMS IFunctions 


Proprietary rights can probably be adequately safeguarded through non- 
disclosure agreements and policy regulations. Hilltary security will probably 
be effected by sepa ration of subsystem components and black bones. 

3.5 CONTROL, OPERATIONAL OR MISSION 

There Is an Issue In the concept of operational vs. mission control* The 
resulting data system requirements may be different. Operational control 
would be similar for all missions. It may constrain the mission or It may 

result In a more complex data system to accommodate all miss Ions j but It may 

be easier to train operators and to Interface other systems. Mission control 
might differ significantly for each mission. An In-depth understanding of 

both operations and mission applications Is necessary for a balanced 
implementation. Some partitioning of the data system may be the best 

approach. 

3.6 AUTONOMY 

This is a very big Issue and raised several questions. Additional Issues also 
surfaced during this discussion. The first was the question of how long the 
Space Station would remain autonomous (several days, one month, between 
shuttle flights, etc.)? Autonomous period In study ground rules Is 90 days. 
It was felt that this is too long. With five shuttles. It may only need to be 
autonomous for several days. Thi minimum period was not defined by panel. 

Another question was, “do both manned and unmanned conditions need to be 
considered?" 

There was a lengthy discussion on “autonomy." It was unanimous that the Space 
Station be capable of autonomous operations. That meant different things to 
different people. 

o ’ that the Space Station and personnel could operate for extended 
periods without benefit of ground support or other systems. 

o that the Space Station system, Including the ground segment, could 
operate for extended time without support from other non Space 
Station systems. 

o that the Space Station In orbit could operate without human 
intervention, continuing automatically to acquire data and perform 
Its function. 
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o that the Space Station system^ including both the in orbit and 

ground segments, could operate automatically without human 
intervention* 

There are two reasons the Space Station needs to be autonomous: 

o reduce the number of operators - NASA wants less than 100 people In 

the control centers because they cannot afford £hem and they don't 
really need them unless there's an emergency. Apollo had 900 people 
and Shuttle has 600. 

o DoD wants the Space Station to be autonomous in case the ground 

station is lost, to increase chance of surviving on the Space 
Stat ion. 

Three areas for autonomy were defined as: 
o Health and Maintenance 

o Routine (those normally performed by the ground station) 
o Navigation 

A recent NASA study identified seven levels of autonomy culminating with an 
intelligent robot. 

3.7 GROUND INVOLVEMENT 

Two basic concepts to be developed during the study should have different 
degrees of autonomy. 

6 Approach maximum on-board autonomy, 

o Fair degree of ground support. 

3.8 ROLE OF SPACE STATION IN EMERGENCY 

The role of the Space Station as a national resource during an emergency was 
raised. If a national asset, it may have to survive an attack. If mission 
were military, it would need a lot more security because of chance of attack 
from hostile nations. It was decided that extreme military applications were 
out of scope of our study. We should assume it is not necessary to plan for 
any specific data system impact. 

3.9 SURVIVABILITY 

The issue of survivability was raised. A lot of redundancy is required to 
ensure survivabi H ty. The question was raised as to whether military 
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applications should be considered here because military men are hired to "put 
their life on the line" in case of emergencies. It is a real factor, but only 
in the sense of natural or accidental threats. We may allow some tempering 
with regard to loss of life. However, some radiation hardening, etc., is 
worth considering. It is probably prudent to expand the system from an 
Initial system with relatively few survivability features. 

3.10 COLLISION AVOIDANCE 

The role of the Space Station as a national resource probably drives the need 
for some degree of collision avoidance as a data system function. The ground 
rule is to detect only accidental objects and not to consider overt 
intentional aggression. Threats such as space debris must be avoided. 

3.11 MANEUVERABILITY 

The function of protection ana safety, particularly collision avoidance, was 
discussed. There is a legitimate need for debris detection and assessment, 
modeling, tracking, and so on. The resulting action is not a consideration 
for this study. If orbital maneuvering, debris sweeping via a teleoperator 
type device, directed energy destruction, or other schemes are employed, they 
will be devised by others. 

There was some discussion on station keeping and orbital plane changes. The 
general concensus was that we should assume the propulsion system would be for 
drag make-up only. Orbital plane changes would be ruled out. 

3.12 DEBRIS TRACKING 

Detection of debris, especially crosstrack items of small cross section 
measuring just a few centimeters, is a vital concern because of the size of 
the Space Station and the length of time In orbit. There are four sizeable 
objects in Space Station's intended path. Possibly, defense against debris 
should be provided. Question was raised, "do we need a data base of space 
debris on-board?" Other items are also of such a small size that they may not 
be In the data base of tracked items. These are the real concern and may 
require an active detection subsystem. 
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3p13 fault tolerance 

There were additional topics related to autonomy and survivability Including 
health, maintenance, and navigation. Automatic fault detection, Isolation, 
and reconfiguration was discussed. Some replacement and repair would be 
performed by human Intervention. Fault tolerance design and techniques for 
automatic fault detection and Isolation are reasonably well in hand for 
digital systems. That Is not true for analog and hybrid sytttems. 

3.14 SURVIVABILITY THROUGH DISTRIBUTION 

The concern for survivability In a collision situation may leef) to other data 
system considerations. For Instance, the distribution of functions with some 
redundant capabilities In case some circuitry Is lost. Automatic damage 
control Is probably one of those subsystems that will have an Interface but 
will not be addressed in any detail. Damage control may include certain 
sensor processing to detect the problem, some decisions as to Its severity, 
and then reactions such as power interruption, system segmentation, bulkhead 
closing, purging, and so on. 

3.15 MAN'S ROLE IN APPLICATIONS 

There was extensive discussion on the role of man in the system. There were 
two camps when It came to the applications data processing. In the 
Information extraction activity, there are numerous cases of evidence that 
manned Interaction is more cost effective than complete machine automation. 
For earth observation activities, man in the loop can pinpoint rare 
occurrences and zoom in on them to analyze their cause and effect. 

3.16 MAN'S ROLE IN OPERATIONS 

In pursuing the discussion of the role of man and the influence on data system 
functions, the need for man to effect repairs was emphasized. Built-In fault 
detection, etc., can direct man to the replacement items. 

The shuttle provides a case history with regard to autonomy. When first 
conceived, the shuttle would fly automatically without pilot interaction. The 
astronauts did not like that and insisted on manual control. They then 
discovered it was too complex and needed help in the form of increased 
automation, which has now been effected. 
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3.17 AUTOMATION 

Because of the differences In understanding of autonomy, v^e might want to make 
the distinction between automated and man interactive. 

Automation can reduce operating costs. Apollo required about 900 people at 
consoles; Shuttle requires about 600. The goal for the Space Station is below 
100 . 

It is hard to keep people at a console when nothing happens. There is a need 
to have a much more autonomous system. One approach is to design the system 
architecture such that as the system evolves, Increased intelligence can be 
Incorporated to perform more functions automatically and even adaptively. 

3.18 CREW MAKEUP 

A point was made of crew makeup having an impaet on data system requirements. 
There is a difference in philosophy the approach NASA has used, which is to 
select “supermen" and then build the data system to support them. The 
military approach has been to establish requirements for the system, partition 
functions to the data system or the personnel, and then identify the necessary 
skill level required based on a task and skUls analysis. We should assume 
man is not a superman; neither is he a drop-out. 

A separate NASA group is working the human factors area for Space Station. We 
should probably not stress this area. 

3.19 MAN-RATED DATA SYSTEM 

The idea of “man-rated systems" may not be continually viable in the previous 
sense, although no pronouncement on that policy may be expected. A greater 
degree of risk may be acceptable and to some extent, the man-in-the-loop may 
be expendable. A few extra data channels may be required. 

3.20 MAN SUPPORT 

There was some discussion on the role of other subsystems such as medical 
systems. The data syst >m must interface to them and in some cases provide 
data management functions. 
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with 6, 10, or 15 people on-board, the Space Station Is a potential Incubator. 
What are medical implications? In the past there have been no major problems. 
A thorough medical examination before missions has prevented serious 
difficulty. 


3.21 MAN/MACHINE INTERFACE 

Han/machine interface is clearly an issue for the data system study which we 
should address. The extensive involvement of graphics was discussed and 
indicated as an accepted part of the generally friendly man/machine interface 
requirements. 

3.22 ACCIDENT CONTAINMENT 

The idea of accidental problems was discussed. No nuclear power sources are 
being considered due to political considerations. A reactor can be launched 
cold and come back in safely. There was some disagreement if this is feasible 
from a safety standpoint. Damage detection, assessment, and containment 
functions In support of other subsystems are legitimate roles for the data 
system. Lithium batteries can provide backup power. 

A high degree of automation of such subsystems as power and life support can 
be expected. The data system will perform some related functions. For this 
study, we should not dwell on them but merely recognize them. There are other 
working groups addressing other subsystems. We should look at the Sky lab 
function list as a good starting point. 

3.23 DATA BASE 

The approach to providing the necessary data base was discussed. There is 
probably a need to provide multiple accesses to distributed, heterogener»us 
data bases. The Space Station could be a node in the applications data 
service (ADS). 

There is an issue of accessing data bases on the ground as opposed to having 
all data bases on-board. The idea of staging, which has to do with loading 
necessary data bases Into readily accessible memory prior to when It wiH be 
needed, was also discussed. 
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3.2^* INTERNATIONAL INVOLVEMENT 

The question of international Involvement was raised. The answer was yes; 
current NASA plans point to Involvement of other nations. A restrictive 

assumption as to the data base Is It will be English and the numerals will be 

Arabic. 

3.25 MISSION MIX 

The need to accommodate a continuing change of mix of subsystems was 

recognized. The need to provide some degree of interface definition and 
standardization with a definite modularization of the data system is an 
important concept to maintain low life cycle cost and technological 
transparency. 

3.26 SCHEDULING 

Work planning and scheduling, including experiment and application activities 
is an important role for the data system^ Ground network scheduling may 
prohibit the users from using the TDRSS because o^ high priority military 
mission. If scheduling is done on-board, this becomes a data system problem. 

3.27 COMMUNICATIONS 

The need for the Space Station data system to provide communication services 
was discussed. Some free flyers are expected to be required for special 
orbits or other reasons. The Space Station will not compete with TDAS or 
TDRSS but there will be a need to provide some communications relaying, up, 
down, and as a cross link with other satellites. There will be a need for 
data storage and ephemerides determination for antenna pointing, and data 
acquisition. 

Communications need to include commercial (i.e., to a commercial communication 
satellite or direct to ground) channels. 

3.28 VIRTUAL APERTURE SENSORS 

The need to process data from virtual aperture sensors was discussed. This 
seems to be a definite need. While there may be some large pushbroom arrays 
constructed, the thermal stresses will prevent the construction of 

sufficiently large antennas to achieve the desired resolution. Both SAR and 
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LIDAR are viable sensor programs that we can expect to see deployed on the 
Space Station. 


3.29 ATTITUDE AND POSITION DETERMINATION 

The issue of attitude and position determination was raised but little 
discussion or exploration of ideas took place due to time constraints. Time 
annotation must be Included, This should probably be a service provided for 
all applications, experiments, and subsystems, it needs some investigation. 

3.30 TIME PHASING OF ISSUES 

The need to identify a time phasing for the issues is important since they 
obviously will not all be implemented at the same time. 

3.31 MISSION TYPES 

An approach to driving out Issues based on applications and uses of the Space 
Station was employed. A list of generic applications was developed with 
specific considerations of the impact on the data system as a result (see 
Table 5). 

Different types of missions Were discussed. The idea of robotics within the 
materials processing was considered as only incidental to the data system. 
Some interfaces may be required, but the robotics would not be included. 

3.32 ORBIT IMPLICATIONS 

In discussing missions, it was determined that earth observations might not be 
a big driver for the assumed 28.5® orbit. However, if this is a precursor to 
a near polar orb iter, then the Impact should be considered. 

We may want to relax or modify the assumption of 28.5° orbit for just such 
reasons. (We probably will, but without admitting the added loading of data 
system requirements caused by such phenomena as added radiation hazards to 
personnel and components.) 
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3.33 MICRO-GRAVITY APPLICATION 

Zero gravity (micro-gravity) research represents applications In addition to 
those covered by materials processing and life sciences. The concept of 
artificial gravity has beiin abandoned, so far, as not necessary and causing 
undue additional problems. 

3.3^ SPECIAL SPACE PLATFORM CONSIDERATIONS 

The question waS raised here ''If we can do it now on satellites, why do we 
want to duplicate it on the Space Station?" Answers were 1 ) we now do the 
minimum because of the cost requirements, and 2 ) sometimes a real time 
decision is needed which cannot be done without the man-ln-the-loop. These 
implications are important when considering the Space Station Data System. 

3.35 LIFE SCIENCES 

Life sciences include medical and biological applications. 

3.36 environment MONITORING 

There will be a need to monitor the close environment, both internal and 
external to the Space Station, to analyze effects of contamination on sensor 
characteristics. This will have some data system implications. 

3.37 OTHER OPERATIONAL APPLICATIONS 

Satellite repair/refurbish/service and space construction should be 
cons i dered. 

3.38 WEAPON SYSTEM RESEARCH 

Weapon system research such as directed energy is more of a military 
application with which we can do little. We should define it out of study. 

3.39 TECHNOLOGY 

Additional issues were approached from a technology viewpoint. A list of 
technologies available now or in the near term was derived, along with any 
resulting data systems issues (see Table 6 ). 
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3.^0 FIBER OPTIC COMPONENTS 

Advances and expected advances In fiber optics components were discussed. 
Couplers are presently a problem but will probably be solved. The 
availability of fiber optic technology In the time frame of Interest may be 
assumed. 

* 

There are plans for a Long Puratlon Exposure Facility (LDEF) to evaluate new 
components, such as fiber optic elements, In the space environment. 

3.41 INTEGRATED LASER COMPONENTS 

Bell Labs currently has a working device generated by molecular Implantation 
(which literally means built molecule by molecule), which has several tiny 
lasers built around an 1C chip. 

3 . 42 COMMON I CAT I ONS FREQUENC I ES 

In the communications area, SHF and EHF can be expected with millimeter waves 
being used for crosslinks. There Is no need for very low frequency 
applications on the Space Station. Laser links will provide links to ground 
and other free flyers. One study said one gigabit/second rate will be needed 
in the 1990s. 300 MB/S down link capability exists for TDRSS. 1 SAR + 1 

Thematic Mapper would exceed 300 MB/S. 

Work Is progressing in the 20, 30, 40 GHz carrier region with Gall I urn Arsenide 
components. 

Active aperture antennas in the 20/30 gigahertz range will have some impact on 
communications, fault tolerance, and software drivers. This is currently 
adequately funded and can be expected to be available. Gallium Arsenide 
components to replace short life-time traveling wave tubes will also be 
important. 

3.43 data COMPRESSION 

Data compression is a viable technology. Communication bandwidth requirements 
will be reduced both through on-board information extraction (automation and 
man-in-the-loop) and channel coding. 
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3.^^ DATA SYSTEM ARCHITECTURE 

Computer system architecture and access Is an Important technology with many 
Issues. Modularity of the data system architecture and the software Is a 
must. The Interfaces must be well defined and standardized. ’’User education" 
will play a major role. The users must know what the Interfaces are and must 
be made to understand that certain guidelines and standards must be Imposed. 
Then the pieces can be "plugged In" with minimum Impact on the rest of the 
system. There must be provisions for different modes of operation according 
to degree, with different change authorities required. 

3.^5 PROCESSING CONTROL 

In the technology of computers and processing, the control of the processing 
Is probably the most critical concern. 

3.46 STANDARDIZED INTERFACES 

The concept of standardized interfaces to station subsystems and experiments 
Is important. The overall data system architecture must accommodate changing 
conditions of Interfaced subsystems. (This has some Important implications on 
software addressed In later notes.) 

3.47 USE OF NEAR COMMERCIAL COMPONENTS 

The use of near commercial components in space provided for considerable 
discussion. The biggest problem involves safety. Certain materials are 
prohibited in space. Often commercial vendors do not know if they are using 
them or not. The relaxation of performance and reliability requirements for 
space hardware may be the best way to achieve economy. Space qualification 
has the added disadvantage of introducing a two or three year delay in the 
availability of new technology.- Adequate attention to logistics, on-board 
replacement of failed components, and redundancy may be a better approach. At 
the same time, better knowledge dissemination and standardization of space 
materials may be the optimum approach- The space qualification problems of 
ICs are slight. The problem is with the multilayer boards, soldering, 
insulations, etc. , due to outgassing and safety hazards. 
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A snore desirable approach is to achieve economy by providing spares and 
requiring lower aval labi I ityi have man- in-the- loop to effect repair* This 
affects the whole position on architecture. 

3.A8 SPACE QUALIFICATION 

The initiation of some degree of space qualification of emerging technologies 
appears desirable. NASA presently is doing Just that for optical discs. 
Progress In data system technology and its subsequent applications in space is 
being addressed. For example, Storage Technology in Colorado has a 60 million 
dollar development program for a commercial laser optical disc system that is 
expected to be available in I98A/85. NASA has a correlary program to try to 
qualify this for space with a one year lag. 

Carousels to increase on-line storage are also being developed for ground 
applications. This could be used for archive or permanent copy. Discs could 
be shipped to the ground on resupply visit. 

3 .A 9 ARTIFICIAL INTELLIGENCE 

There was some discussion of algorithm development and alternatives such as 
artificial intelligence (Al). Can the data system develop some of the 
required algorithms in real time? There did not seem to be much support for 
the position that this is possible in early phases of the Space Station. NASA 
is interested in Al. They recently had William B. Gevarter of National 
Bureau of Standards perform a survey and prepare a report NBSIR-82-2505 "An 
Overview of Expert Systems" - May 1982 (J. Neiers has a copy). 

Heuristic planning for mission scheduling is promising. NASA has a plausible 
inference system call "DEVISER" that performs automated intelligent 
scheduling. It was developed by JPL for planetary "flybys." 

3.50 RADIATION HARDENING OF VHSIC 

Space radiation hardening is a necessity. NASA and other agencies have 
programs addressing this need for VHSIC. There is an issue here as to whether 
VHSIC will be radiation hardened. 
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3.51 DATA BASE MANAGEMENT 

The whole area of data base management Is very Important. Recently It has 
become easy to buy data base management systems. Re 1 at:|ona 1 systems are In 
vogue. The experience has been, "Everyone needs DBMS; they are easily 

purchased -- and they don’t work very well." The problem should be 
addressed. 

There will be a need for a large data base. It will also be distributed and 
heterogeneous. That should be recognized and addressed. 

3.52 SOFTWARE 

In related discussion, the cost of software development and verification must 
be reduced, Some Ideas on natural language programming and machine-assisted 
code generation must be explored. There are two major areas of Interest In 
NASA today; 

o development of cost effective tools that will reduce the cost of 

software, and 

o reliability and the development of tools to ascertain reliability. 

3.53 SOFTWARE FAULT TOLERANCE 

The Impact of fault tolerance on the software is an Issue to be addressed. 

3.5^ ON-BOARD SOFTWARE CHANGES 

There was considerable discussion over the question "Will software changes be 
allowed on the station?" This was probably the most controversial Issue 
addressed. The panel was divided and opinionated as to the correct answer. On 
the one hand, permanent and continuous operations while specific mission mixes 
change almost dictate some degree of on-board software changes. The role of 
the man Interacting with the experiments and operational sensors for 

serendipitous observations also drives the need for semi-real time software 
changes. On the other hand, experience and related horror stories dictate 
definitely "NO." 

SUMMARY 

Those Issues and technologies that were considered of high priority and 
deserving special attention were identified on the appropriate tables. A 
first attempt at Identifying key areas Is presented in Table 7 . These are all 
high priority topics with no significance implied by their order. 


Table 7» Key Areas 


Architecture 

Autonomy 
Data Base 
Functions 
Logistics 
Man's Role 
Software 

Space Qualified Components 


ll.l ARCHITECTURE 

The data system architecture should exhibit features of flexibility, 
technological transparency, and fault tolerance. Flexibility and 
technological transparency can be enhanced by defining standard interfaces. 
This concept of modularity and standardized interfaces should carry through to 
Include software. Fault tolerance includes an attention to survivability 
through functional modularity, distribution, redundancy, and protective 
functions. 


1».2 AUTONOMY 

The data system should exhibit characteristics of autonomy as defined in 
various modes that include survival without external systems or ground support 
and automatic operation without human Intervention. Autonomous operations is 
a driver for the architectural implementation. 

k.3 DATA BASE 

The data base, Its architecture, contents, size, and location are Important 
factors in the data system. A distributed data base, with a portion being 
ground resident should be at least one alternative. Technological advances in 
access methods, including user friendly natural language query systems should 
be considered. 
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ii.k FUNCTIONS 

A dichotomy of functions of the data system should be Identified, One 
partition should Include housekeeping or operations type functions. The other 
partition should be application oriented. These two partitions may be thought 
of as operation oriented and mission oriented. Especially, the mission 
functions will be dependent upon a comprehensive consideration of potential 
applications. 


^.5 LOGISTICS 

The data system will play a major role In logistics and logistics management. 
Because of the Indefinite lifetime and manned presence, the entire operational 
philosophy will be different from previous spacecraft. Fault detection, 
isolation, and manned repair will be normal. Spare parts management will be a 
significant role for the data system. The whole reliability requirement will 
also change with an emphasis on availability. 


MAN'S ROLE 

The role of man Is yet to be decided, but he will definitely be an If^tegral 
part of the overall data system. The Interface must be friendly, with both 
visual and audible interfaces. interactive analysis of extracted Information 

may be assumed. The guided repair role will also fall to man. Routine 
operations will likely be automated. 

k.7 SOFTWARE 

Software will be a significant factor In the data system. An emphasis on 
tools for lower cost development and for Improving software reliability |s 
suggested. Natural language processing and heuristic Implementation of some 
functions, particularly planning, Is worth Investigating. 

^.8 SPACE QUALIFIED COMPONENTS 

The correct consideration of space qualified components will have a major 
Impact on life cycle cost. The changing role of manned presence and 
Indefinite life calls for new considerations of reliability and 

maintainability. Technological advances of commercial components should not 
be forfeited because of excessive space qualification processes. Yet, because 
of safety concerns, especially outgassing of materials, commercial products 
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cannot be used carte blanche. A relaxation of reliability requirements along 
with a materials certification and education program probably offers the best 
potential for reduced life cycle cost. Some consideration should be given to 
advancing this idea during this study. 


Prepared by: 


^J.W. Neiers 




Program Manager 

Space Station Data System Study 
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APPENDIX C 


DEFINITION AND DERIVATION OF EXPRESSIONS FOR 
RELIABILITY, COMPUTATIONAL CAPACITY, AND DEGRADATION 


DEFINITION AND DERIVATION OF EXPRESSIONS FOR RELIABILITV, COMPUTATIONAL 

CAPACITY, AND DEGRADATION 

The terms or parameters reliability, computational capability or capacity, 
and degradation are defined and n^athemat leal expressions are derived relating 
these to the idealized model to be considered. Although an intuitive feeling 
of the meaning of these terms presently exists, a brief qualitative definition 
of each is in order to possibly avoid later confusion or misunderstanding. The 
standard definition of reliability will be used which is the probability of 
success of the particular item under consideration over some period of operation. 
It will be assumed that the sample space is dichotomous, l.e., an item either 
falls in a good or a bad category; thereby, a discussion of what constitutes a 
failed circuit, module, etc., is avoided. Degradation, as applied to parallel 
processing or multiprocessing elements and not to individual circuits, means 
the dropping off of parallel elements, or in some cases, a parallel processor, 
as failures occur. As used herein, it will apply only to multiprocessor operation 
for the fault-tolerant mode of operation, reliability represents a form of 
degradation. If a multiprocessor init ially starts with n processors, after 
some period of time, one fails leaving n-1 available processors, etc. Thus, 
the term "graceful degradation" is often applied to this type of application. 

It Should be noted that this definition of degradation also yields instantaneous 
computation capacity; however, for the purposes herein, coraputaional capability 
or capacity will be derived from both the reliability and degradation parameters. 
It simply represents the area under the degradation - time curve and is defined 
as follows; In the case of n initial modular multiprocessors, after some 
period of time one module fails; thus, the number of computations performed up 
to that time is the product of n processors and the time increment from initiation 
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up to when the first failure is expected to have occurred. Similarly, the 
mean time of the second processor failure is determined and the product of 
n>l processors and the time difference between the expected values of the 
first and second failure yields the computing capability over this time frame. 

This t/^uantity is then added to the previous value to obtain total computational 
cap'icity up to the second failure. Notice that a module failure does not 
necessarily result in a processor being removed from the system. This is only 
the case when the minimum number of modules available in any stage drops below 
that previously available in the system. If r represents the maximum number 
of processor failures allowed, then n-r is the minimum number of modules 
required in any stage in the system, and the summation must stop when the mean 
or expected number of functional processors has fallen below this number. Briefly 
then, computing capability represents the total number of operations performed 
by a multiprocessor system before the system becomes too minimal to handle the 
total application requirements. Computational capability will be normalized 
about a single processor; i.e. , it is represented as the ratio of the computa- 
tions expected from a multiprocessor system to those expected from a single 
processor before each system fails. Although, as far as is known, this definition 
of computational capacity is unique, it is by no means the only definition which 
can be applied. However, it serves the purposes of this paper and allows 
tradeoffs in the desired parameters. 

With these brief preliminaries disposed, we turn our attention to thfe 
main problem at hand; i.e., in treating the effects of modularity upon reliability, 
computational capability, and degradation, and indicate how it can be advan- 
tageously employed in a single architectural design which is automatically 
reconf igurable to a wide range of applications. Consider the idealized modular 
system shown in Figure 1, A single processor system has been divided or segmented 
into m modules, denoted by **'* ^lm» will be assumed for simplicity 
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to have equal rcliabllitieB. Equal reltabilities imply that the system has 
been segmented into modules of equivalent complexities. Each of these modules 
Is then replicated n times. A stage will be defined as n replications or a 
group of functionally identical modules; thus, modules Mn» ^21' •*" ^1 
in Figure 1 form a particular stage, It will be assumed that any module in 
one stage can be connected to and used with any module in the next stage. A 
switching element is used with each module and can mathematically be thought 
of as being functionally part of that module. The switching element is used 
either for error detection, isolation, and module switching when the system is 
operating in the high reliability mode or as an interconnection switch allowing 
any module of one stage to be connected to any other module of the next stage 
when the system is operating in the multiprocessing mode. 

Let R represent the reliability of a simplex processor; e,g., the product 

of the reliabilities of modules ^ 2 * ^In’ modules into 

which a processor has been segmented are assumed to have equivalent reliabilities, 
the reliability of a single module Rjjj, is given by the expression 

= [11 


Let be the reliability of the decision and switching element and let a 
be the complexity of this element relative to that of the module; i.e., 

a= , where n^ and n^ are the number of equivalent component 

parts, gates, or chips, in the switching element and module respectively. The 
reliability of the switching element can now be expressed in terms of module 
reliability yielding 


R - R** 

- •'m » 
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or, the reHabillty of the switching element expressed in terms of a simplex 
processor is given by 

R. = . 


Because a switching element is assumed to be employed with each module, 
mathematically, these reliabilities can be lumped together and treated as a 
single identity, denoted by and expressed by the relationship 




The reliability of a simplex processor is usually assumed to be given either 
by the binomial or Poisson distribution each of which leads to the expression 

R 


where X is a simplex processor failure rate, or y is the mean time between f 
(mtbf) and t is the system operating time. 

The probability that no failures have occurred in the total system 
consisting of nm modules is equivalent to the probability that all m stages 
contain n functional modules and is found from the binomial distribution. 

This probability is given by the expression 



The probabilities of one or less, two or lessj and r or less failures in all 
m stages are^ given by the expressions 


m 


’’»<! =[Rjt"Rj'’('-Rc)]" 

=[r"^ C-Rc) ♦ RrhiV] 


p 4, = [R.%»Rr’o-R.» » ♦ ‘"“"-'’•Vi’"-' '- Rrn-Rc)'] 
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respectively* Equ^ltion (8), therefore! expresses the probability that there are 
at least n- r functional modules in each stage or, consequently , that the system 
contains at lea^t n-r functional parallel processors. Thus, r represents the 
maximum number of failures allowed in any stage or the maximum number of failed 
processors permitted. This equation will be used to represent overall system 
reliability when operating in the high reliability mode. 

An auxiliary equation may be developed which will be extremely useful in 
describing the mean number of processors expected to be functional at any instant 
in time. Notice the probability that there are exactly n-1 f-unctipnal modules 
in each stage or that there are exactly n~l functional parallel processors is 


=1 " ^ K <1 

p.,, O') 

Therefore, the probability that there are exactly n-r operational processors in 
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the system Is given by the expression 

Equation (10) which can be evaluated through recursive operations can also be 
expressed formally as 


do] 




m 


. I^r; + »Rr'o-*.) R;-'(i-R,)'j" 


- [r." * .r:-'(i-«.>* R."-'* '(t-R.r . 


nil 


The mean number of parallel processors expected to be functional at any 
time is a measure of the degradation of the multiprocessing system f/nd is found 
again by the binomial distribution and can be expressed in the form 


M(») 


f 

(n-i)P,_|(t) , 


i =0 


Expansion of Equation (12) through substitution of the previously derived 
equation yields . 

n[^R"j”+(n-l)||^R; +nR;"V-Rc)]'"- [rJ]"" 

♦ (-0 j[ r;-'(I-R.)']” 


- rR;+nR;*'o-R.) 




(n)(n-1)... (n-r) _n- 

(r-l)f 
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where /j and are understood to be functions of tlfne since R^. is found from 
Equations (3) and (A). Equation (13) expresses the mean number or the expeqted 
number of functional parallel processors after some specified operating time 
and is the analytical expression which will be used to represent system 
degradation. 

A simple example may help clarify some of the mathematical symbology used 
in the above development. Suppose three fair coins are tossed simultaneously. 
What Is the expected number of heads? By a "fair coin" is meant one where on 
any particular toss the probability of a head equals the probability of a tall; 

P * 1/2. The probability of exactly three heads, two heads, and one head is 
P^, SP^Cl-P), and 3P(1-P) respectively. Thus, the mean number of heads Is 
found by applying Equation (12) which in expanded form yields 

M = 3 
= 3P 

Since P=l/2, 
yu=3/2. 

In the work which follows, JX will be rounded to the nearest integer value. 

We now have the tools to develop an analytical expression for computational 
capability. This term or parameter may be considered from several different 
aspects. Equation (13) yields the number of parallel processors expected 
to be operational at any instance in time; therefore, it represents instan- 
taneous computing capability. Herein, computing capability will be defined 
as a relative quantity representing the ratio of the total number of operations 
performed by a modular multiprocessor system before it can be expected to have 
dropped below its minimal requirements to the number of total operations obtained 
from a single processing unit before it is expected to have failed. Thus, 
when Equation (13) is plotted as a function of time, the total computational 


+ 2 j3P*(l-P)J 1 1 J^3P(1-P)J 




capability Is represented as the area under the curve between t-0 and the 
point In time where • i.e., the point In time where the 

Integer value of the number of proceasorB that are expected to be functional 
drop below the minimum specified number. 

Mathematically, the computational capability of a system can be expresBed 
BB the product of the mean number of parallel processorB expected to be opera- 
tional over some Incremental time frame and the value of that incremental 
time frame. 

ThuB, 

C(At)= At^l(At) 

C(2At)=: At^i(2At) 

I I 

C(iAi) =At**l(jAt) , tW) 

where A* represents an increment of time and ^l(j At) is found by 

determining integer values for Equation (13) at successive points in time; 
i.e., t=|At . Therefore, when At is taken as a constant time interval, 
the total computational capability is given by the expression 


C (t) = C( A t) + C (2 A t) + ♦ C (I At) , 


tisi 


or from Equation (14) by the more compact expression 


t/At 

C(t)= At^^i(iAt). 
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EVALUATION OF SYSTEM PARAMETERS FOR AN IDEALIZED COMFJTATIONAL SYSTEM 


The parameters reliability, computational capability, and degradation 
vhich were analytically defined and derived will now be numerically evaluated 
for an idealized system. The term ’^idealized system" Is used because of the 
following simplifications; 

(a) A single or simplex system is assumed to be segmented into 
modules of equal reliabilities; i.e., equivalent complexities. 

(b) For the high reHability mode of operation, the effects of the 
switching element have been neglected. 

(c) For the high computational mode of operation, the efficiency of 
a multiprocessor has been neglected; i.e., assumed 100 percent. 

In Figure 2, reliability, degradation, and computational capability, as 
determined from equations (8), (13), and (6) respectively with substitution of 
equation (4) have been plotted as a ftmetion of normalized time for a six- 
processor system. Time has been normalized about the mean time between failures 
(mtbf) of a simplex system. Thus, at K«=l, a single processor would have a 
reliability of 0.368; it would have accomplished one machine's worth of 
computations, and it could be expected to have failed at this point in time. 

For each parameter, the number of modules into which a system is segmented 
varies between one and five. In this figure, it is assumed that only one module 
out of each stage or one computer system out of six is required to be functional. 
The stairstep curves represent computer degradation. For example, it is 
expected that the system will undergo transactions from a two-processor to a 
one-processor system at K*1.375, 2.050, 2.625, 3.150, and 3.650 depending on 
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whether m-l, 2, 3, A, or 5 respectively. The points In time vbcre the system 
csn be expected to degrade, l.e. , where each failure In the system Is expected 
to occur, Is clearly Indicated as a function of m and the normalized operating 
time. 

The area under the degradation curves has been Integrated with respect 
to normalized operating time and represents computational capability. For 
example, with m-1, the system can be expected to yield approximately 5.5 times 
that of a single processor. This point corresponds to K»2.45, where the number 
of systems expected to be operational drop below 0.5 and thus, the curve is 
terminated. Without using Integer values for the expected number of operational 
processors, when the area under the curve is integrated to t»= « ^ a computa- 
tional capability of six is obtained; i.e., with six parallel processors which 
are not modularized, one could expect six times the processing capability as 
with a single processor. Thus, the end point of the computational capability 
curves indicate two quantities. 

(a) When read with respect to the ordinate, it represents total 
equivalent computational capability relative to a simplex system. 

(b) When read with respect to the abscissa, it represents the point 
in time where the last computer system is expected to have failed (an 
exception is m>°5 where operating time was limited because of scale). 

Thus, for a modular six-processor system with tn«l through 4 respectively, the 
total computational capabilities are 5.5, 8.0, 10.25, and 12,25; the operating 
times where the last system can be expected to have failed are 2.45, 3.6, 4.6, 
and 5.5. The total computational capability of an idealized system is, therefore, 
directly proportional to the time the system is expected to be operational. This 
follows directly from definition and is clearly indicated by the figure. The 
effect of modularity on both degradation and computational capability is well 


demon sc ruled through these two seti'i of curves; a six-proccssor system with 
m“'^i yields more than twice the eomputatlonaj capability obtained from six 
parallel processors with m>l and can be expected to be functional more than 
twice as long. 

The effects of modularity on reliability is demonstrated in the upper set 
of curves. For example^ with K-3.6 reliabilities of 0.155, 0.4A0. 0.690, 

0. 840, and 0.915 can be expected for m**l , 2 , 3, 4, and 5 respectively. It 
has been assumed that at least one module per stage must be functional for an 
operational system. Conversely, for a given reliability goal, it can be seen 
that modularity increases the operating time over which the system is expected 
to be operational. For instance^ with a reliability goal of 0.9, values of 
K-1.15, 1.90, 2.55, 3.15, ond 3.75 are found for m-1, 2, 3, 4, and 5 respec- 
tively. Thus, by Increasing m from 1 to 5 the operating time frame to main- 
tain a reliability of 0.9 has been extended by a foctor of 3.3. 

As an example, assume a hypothetical system consisting of six processors, 
each of which has been segmented into four modules. Assume that a redundancy 
technique is employed where only one of six modules is required in each stage; 

1. e., r«5. Further, assume that in the high computational mode a single pro- 
cessor can provide the minimum computational requirements. What can be said 
of the system's reliability, computational capability, and degradation? From 
Figure 2 for mw4, in the high computational mode, the system is expected to be 
functional for a period of K«5.55 times as long as a simplex processor. The 
first, second, third, fourth, and fifth failures can be expected to occur at 
K«0,100, 0.475, 1.075, 1.900, and 3.150 times the mtbf of a simplex system 
respectively. The total computational capability of the system is expected to 
be greater than twelve single non-modular processors operating in parallel. If 
used in the high reliability mode, a reliability in excess of 0,9 is obtained at 
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K=3.70. A system consisting of six parallel processors (m=l) would have a 
reliability less than 0.140 at this point in time. 

The parameters of a six-processor system where at least two processors 
are required to be functional are shown in Figure 3. This figure is used 
similarly to the previous figure. Notice the decrease in the times at which 
failures are expected, the computational capabilities, and the reliabilities. 

The results obtained herein have demonstrated that by modularizing a 
processor system, reliability, computational capability, and system operating 
time can be significantly enhanced. 
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LIST OF SYMBOLS 


Shaping constant used In determining complexity o£ the switching element. 

Shaping constant used in determining complexity of the switching element. 

Computing capability normalized about the capability of a single processor 

Lower index of summation representing the least number of failures which 
can occur. 

Number of modules into which a simplex system has been segmented. 
Normalized system operating time factor. 

System operating constant used in determining multiprocessor efficiency. 

System operating constant used in determining multiprocessor efficiency. 

Total number of equivalent components (discrete parts, gates, chips, etc.) 
in a simplex system. 

Number of module replications in each stage, or the total number of 
parallel processors in the system. 

Number of equivalent component parts or gates in the switching element. 

Probability of success of the total redundant system where x is the 
number of failures that are expected to have occurred in each stage 
and r the maximum number of module failures allowed in each stage. 

Reliability of a simplex system. 

Reliability of the combined module and switching element, 

Reliability of a decision and switching element. 

Reliability of a single module. 

Maximum number of module failures allowed in any stage; n-r represents 
the minimum number of operational processors required. 

System operating time. 

Increment of system operating time. 

Throughput of the multiprocessing system. 

Relative complexity of the decision element when compared to that of a 
module. 


t) 

^ Efficiency of the multiprocessing systemr 
"X Failure rate of a simplex system. 

/* Mean number of procesBors expected to be operational at any instant 
in time, 

A Integer value of mean number of processors expected to be operational 
^ at any instant in time. 
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